5 ms·
It just seems to me that this is the exactly wrong way to solve a programming problem. If the problem boils down to "I want some variables (almost always test f
by 90s_dev 1y ago
It just seems to me that this is the exactly wrong way to solve a programming problem. If the problem boils down to "I want some variables (almost always test function names) to be more human readable", the solution should never be "hey let's add this feature to the core language and make identifiers use any ASCII string! I dunno, maybe I'm wrong here and being overly critical. But to me it just screams "Swift has lost the plot."
- bbatsell 1y agoThe HTTPStatus enum example is a good one, but the backtick syntax is _rough_. I would only ever use the Type.case form in practice. The test stuff is basically a way to create BDD-style test names, which is kind of just a preference thing. I can’t envision myself using it for anything other than weird case names (I already use case `default` quite a lot because it’s such a useful word), but maybe some interesting DSLs can come out of it? I would not have prioritized that change personally.
- 90s_dev 1y agoI would not have even approved it. But that's just me.
- tiltowait 1y agoThe backtick syntax for enums is rough, and typing out the full Type.case form negates one of Swift’s niceties (the ability to just type .case if the compiler can tell which enum is in use).
- rTX5CMRXIfFG 1y agoThe HTTP status enum example is a _terrible_ one. If you need to represent HTTP statuses and call them by their integer names, why not just pass the damn integer itself? It's exactly what you get in `HTTPURLResponse.statusCode`, and you can already `switch` against it. Already not looking forward to the code that undiscerning devs will mindlessly write just because someone with a huge following wrote a blog.
- dagmx 1y agoYou can’t exhaustively handle an enum with just an integer.
- layer8 1y agoYou want to exhaustively handle all 500 valid HTTP status codes (cf. RFC 9110)?
- dagmx 1y agoExhaustive 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
- layer8 1y agoWhen 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.
- dagmx 1y agoOkay? So you cast it to the enum and instantly know it’s not a case you support. It’s built in validation.
- rTX5CMRXIfFG 1y agoEither you’re unaware or you’re arguing in bad faith, but you can switch against integers and pattern-match within integer ranges. The consequences of receiving an unexpected status code is the same—you handle it in the default case, as you would when decoding to an HTTPStatus enum fails.
- 1y ago
- nulld3v 1y agoMany languages have had this feature for a long time. Ruby, ~~Rust,~~ Kotlin, etc... It hasn't been an issue at all. I like that most languages seem to have reached consensus on backticks or other similarily awkward characters for this feature. Typing these identifiers is like hitting a speed bump, which seems to be enough to make devs avoid them except for very specific use-cases.
- 0rzech 1y agoRust does not have this feature. Function names can't have spaces, for example. Underscores are used instead. Maybe there are some macros for arbitrary ASCII strings - I don't know - but it's not a language feature.
- nulld3v 1y agoWow, you are correct! A Rust "raw identifiers" can be a reserved keyword. But other than that, all other normal identifier naming rules still apply... And apparently I never figured this out even after 3 years of Rust lol, thanks!
- nulld3v 1y agoWhoops, I had an edit that apparantly did not submit. My comment is very wrong now, the only language in that list that supports "raw identifiers" in the same sense as Swift is Kotlin. Although I still stress that it has never been an issue in Kotlin.
- jibal 1y agoZig uses @"arbitrary name" It's an important feature for FFI, as well as passing operator functions around. (It seems bizarre to me that you can't do `+` in Swift, but I don't know Swift so maybe there's another way to name such functions.) Also, the Zig library now uses @"..." for variables with the same name as keywords, rather than using ad hoc naming conventions in those cases.
- raydev 1y ago> languages have had this feature for a long time. Ruby Yes, that is precisely why I don't like Ruby, it's actually impossible for tools to reason about many things that would make finding bugs before shipping feasible. Big companies like Shopify have to impose a lot of restrictions on it to make it work at scale, which is silly. Just use a different language! Now Swift may not be in this situation because it's added yet more characters to wrap this nonsense so it is possible to reason about, but it's still just unnecessary, and I will be adding a lint rule against it at work. I don't expect a lot of pushback if any.
- deleted 1y ago[deleted]
- jibal 1y agoTest names are just an example. There are other valid reasons to be able to use arbitrary strings as names--importing functions from other languages and names that clash with keywords, for example.