zlacker

>>todsac+(OP)
I actually liked @T because you would pronounce it as "At T".

You could say "The address at T". Curious why people hated it, I might be missing something.

>>ramon1+J3m
@T had a number of issues. The first was just that it was weird. People tend to not like weird things. Rust developed a reputation for "that language with a bunch of pointer types that are all weird."

The real reason it was removed in the end was just that it elevated a library concept into syntax. Today's Arc<T>/Rc<T> split isn't really possible in an @T world, for example. Shared ownership is a good concept, but you don't need special syntax to indicate it.

>>stevek+lvm
> 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.

>>zozbot+oym
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.

>>stevek+uzm
Swift and TypeScript use ! sort of like .unwrap(). Probably a better use of it than "never" tbh.

>>iknows+IUm
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()