231–240 of 258 posts
Earlier quoted context omitted.
You can’t exhaustively handle an enum with just an integer.
You want to exhaustively handle all 500 valid HTTP status codes (cf. RFC 9110)?
Earlier quoted context omitted.
And no Steve Jobs to pull them down to earth.
Steve Jobs, of course, was always involved in the details of programming languages targeting his platform.
https://youtu.be/Hu-jvAWTZ9o?si=PalSP6POofiRuj3a
I still feel like GUI programming hasn’t progressed in the years since this. Actually they’ve regressed in many ways.
Earlier quoted context omitted.
You want to exhaustively handle all 500 valid HTTP status codes (cf. RFC 9110)?
Exhaustive matching doesn’t necessarily mean you handle every case separately, but it means you aren’t going to get cases you don’t know about sneaking in. With a bare int you can get values outside a range and the compiler won’t help
Regarding the int type, a better solution would be to provide the ability to define a restricted integer type, so that the compiler can help.
Earlier quoted context omitted.
As someone frequently flipping between Swift and Kotlin, while I don’t necessarily feel like Swift is massively superior, I often find myself thinking “why is this so quirky and pedantic” when writing Kotlin. For example, I really really wish Kotlin would adopt Swift style if let/guard let statements. Kotlin smart casting doesn’t work just often enough to not be able to consistently rely on it and the foo?.let { } sy…
The ?.let syntax is terrible. I don’t see how anyone thinks it’s better than doing a normal if != null check.
It sure feels like Swift governance is broken. They're just shoveling stuff in to the language. Individually, most items aren't so bad, but collectively they've got a mess and it's getting bigger fast. None of the decision-makers seem to have the sense or incentive to say "no" to anything. It's sad, because the language had such promise and there are some really nice things in there. Well, at least it's relatively ea…
> None of the decision-makers seem to have the sense or incentive to say "no" to anything. How could you know that? Not all the 'no's show up as a proposal. The proposal template also has an "Impact on ABI" section which you can use to guide your "can I ignore it"-sense. > It sure feels like Swift governance is broken. What is the actual problem though? Not enough features that you would use? But I don't see how this…
Earlier quoted context omitted.
Skip tools is pretty cool and I very may well use it for at some point, but it works by translating Swift+SwiftUI to Kotlin+Compose and I’d prefer a more direct approach that lets me build Android binaries with Swift (preferably with the whole of UIKit available, though that’s not likely).
From the FAQ… > Skip supports both compiling Swift natively for Android, and transpiling Swift into Kotlin. Read about Skip’s modes in the documentation. https://skip.tools/docs/faq/#modes
Earlier quoted context omitted.
As someone frequently flipping between Swift and Kotlin, while I don’t necessarily feel like Swift is massively superior, I often find myself thinking “why is this so quirky and pedantic” when writing Kotlin. For example, I really really wish Kotlin would adopt Swift style if let/guard let statements. Kotlin smart casting doesn’t work just often enough to not be able to consistently rely on it and the foo?.let { } sy…
The ?.let syntax is terrible. I don’t see how anyone thinks it’s better than doing a normal if != null check.
Earlier quoted context omitted.
A big one that I feel is under appreciated is how Swift has rooted out nearly all passing around of untyped data, untyped dictionaries, casting without checking, etc in Apple platform projects. I don’t mind Objective-C when I’m the one writing it and can ensure that the code is responsibly written, but it wasn’t unusual to have to work on existing Obj-C codebases littered with untyped data, casts, etc some amount of…
Just curious, but would it have been feasible to update the Objective-C compiler to reduce these pain points? Or was there issue more intrinsic to the design of the language itself?
You’d basically need to implement the Swift compiler in the Objective-C compiler to get similar type safety, but to make it work you would probably need to change various bits of syntax, drop inline intermixture of C and C++, and remove a lot of Obj-C’s dynamism, basically making it a new language. That’s why Swift was created, and in the past Obj-C’s bracketed smalltalk-like syntax had proven unpopular amongst newcoming devs, so they chose a more mainstream syntax instead.
Earlier quoted context omitted.
Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?
So following this same reasoning Python should become C?
Earlier quoted context omitted.
Exhaustive matching doesn’t necessarily mean you handle every case separately, but it means you aren’t going to get cases you don’t know about sneaking in. With a bare int you can get values outside a range and the compiler won’t help
When you receive an HTTP response, it can contain a status value outside the valid range as well. So you have to handle those one way or the other. Regarding the int type, a better solution would be to provide the ability to define a restricted integer type, so that the compiler can help.
It’s built in validation.