zlacker

[parent] [thread] 5 comments
1. zozbot+(OP)[view] [source] 2025-12-03 17:47:42
> The real reason it was removed in the end was just that it elevated a library concept into syntax.

Rust still does this in all sorts of silly ways, such as the ! type. What's the point of wasting an entire symbol that could have plenty of alternate uses on something that's so rarely used and could easily be defined as either a library type (empty enum) or at least be given a custom keyword, such as `never`? (Introduce it over an edition boundary, if you must preserve backwards compatibility.) The fact that it involves some compiler magic is no excuse; that's why Rust uses "langitem" markers within its core library.

replies(1): >>stevek+61
2. stevek+61[view] [source] 2025-12-03 17:52:22
>>zozbot+(OP)
The standing joke for the last few years is that "the never type is named after its date of stabilization."

I certainly don't disagree that Rust has flaws, for sure. I think this particular one is pretty far down the list, though. I'm not sure what else I'd want to use ! for, and by virtue of it not being used so often means that it's much less of a pain than @T would have been, though I would also argue that 2012 Rust used ~T and @T far more than contemporary Rust does (I still remember pcwalton's mailing list post about how you didn't have to use ~ for comparing strings!) and so was even more painful at the time than would be now.

replies(1): >>iknows+km
◧◩
3. iknows+km[view] [source] [discussion] 2025-12-03 19:36:10
>>stevek+61
Swift and TypeScript use ! sort of like .unwrap(). Probably a better use of it than "never" tbh.
replies(3): >>stevek+tv >>bryanl+XE >>ramon1+Z21
◧◩◪
4. stevek+tv[view] [source] [discussion] 2025-12-03 20:17:17
>>iknows+km
I'm not completely opposed but I'm also not sure syntax sugar for unwrap is a great idea.
◧◩◪
5. bryanl+XE[view] [source] [discussion] 2025-12-03 21:02:06
>>iknows+km
If ! was just used as never it could still be used as an operator, because those are different contexts AFAICT. However, its use in macro invocations seems likely to be more difficult to differentiate from operators.
◧◩◪
6. ramon1+Z21[view] [source] [discussion] 2025-12-03 23:10:07
>>iknows+km
We actually use this version of never a lot in our code at $WORK

```

export function never(message?: string): never {

  throw new Error(message ?? 'Reached an impossible state');
}

const [foo = never()] = dbQueryThatReturnsOne();

```

I guess it's en par with .unwrap()

[go to top]