Hacker News Reader

Comment by 90s_dev | Hacker News Reader

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."

View on HN

Many 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.

Rust 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.

Wow, 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!

Whoops, 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.

Zig 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.

> 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.

Now that you mention it, JavaScript has this inherent problem too:

> foo["hello world!"]()

I'm halfway glad I've never needed to write C++ professionally, but it seems to me like all my TypeScript would probably transliterate to very clean C++31.

The issue is that it’s not a problem in the first place.

Test 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.

The 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.

I would not have even approved it. But that's just me.

The 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).

The 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.

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)?

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.

Okay? So you cast it to the enum and instantly know it’s not a case you support.

It’s built in validation.

Either 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.

Way to start of the comment by being uncivil. You could have made the exact same point without being a jerk about it.

But it’s common to only want to support specific response codes in a context, and people do use enums for that. It’s a fairly common paradigm, and an enum will do all those validations for you so you don’t forget.

Reply on news.ycombinator.com