51–60 of 80 posts
Earlier quoted context omitted.
The right solution was to make union safe with an opt-in way to make it unsafe IMO.
In concrete terms, what would that look like?
> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…
Earlier quoted context omitted.
In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.
TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)
But it's not, hence the aforementioned bikeshedding. When Rust enum variants have data, they're like C unions with automatically-inserted tag checking. When Rust enums don't have data, they're like C enums (they're literally how you do FFI interop with enums in C, which should demonstrate beyond a shadow of a doubt that `enum` isn't categorically wrong). They have the properties of both depending on how they're defined, but at the end of the day they technically have more in common with C enums than C unions (which is why Rust also has `union` for doing C FFI).
> to get C++ programmers on board, wouldn't the obvious name not be "variant"?
Most early Rust contributors were also C++ programmers (due to Mozilla), and I don't recall a single person ever suggesting `variant` as the keyword. I suspect people here are overestimating the mindshare of boost::variant as of 2014.
An interesting aspect of sum types (what Rust calls enums) is that you can implement them in the language as a library if you have real unions, but not vice-versa. Here's my example of sum types being implemented in julia as a regular package: https://github.com/MasonProtter/SumTypes.jl
Earlier quoted context omitted.
In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.
TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)
"OK, let's not go with that then"
"C calls it union"
"OK, we DEFINITELY can't call it that"
> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…
> Haskell, Scala, F#, OCaml, etc. Rust is the first not-weirdass-academic-wtf language to have these features ;) (I love functional programming and apply the functional approach no matter what language I’m using - but why is it that functional languages are always so deeply down the academic rabbithole that they think eg “car” and "cdr” are intuitive names for “retrieve the first element of a list” and “retrieve the…
> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…
There is a group of folks that had learnt these features via Rust, and for whatever reason always praise Rust for "inventing" them.
An interesting aspect of sum types (what Rust calls enums) is that you can implement them in the language as a library if you have real unions, but not vice-versa. Here's my example of sum types being implemented in julia as a regular package: https://github.com/MasonProtter/SumTypes.jl
I don't find "you can implement tagged unions with regular unions but not vice versa" all that interesting of a statement, since one forces tags on you it's not enlightening that you can't remove them, and with any other structuring mechanism you can add tags back in.
The important thing here is that the tags are fundamental to the subtyping relations. So unless your language is flexible enough to let one redefine what it means to be a subtype, then there's no chance of making unions out of tagged unions.
TaggedUnion{A, B} does not have the property that A <: TaggedUnion{A, B}, whereas with regular unions you must have that property, which is a very hard thing to hack into a language after the fact.
Other people have mentioned it in the comments, but they chose the wrong name for these (as did Swift). They're not enums, they're (pick one): - tagged unions - sum types - algebraic datatypes - variants There are some rust packages that transform rust enums into proper enums, the best one being const_table, or my own table_enum. Java got it right except for bundling the data with the Enum object instead of storing i…
> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…
> Haskell, Scala, F#, OCaml, etc. Rust is the first not-weirdass-academic-wtf language to have these features ;) (I love functional programming and apply the functional approach no matter what language I’m using - but why is it that functional languages are always so deeply down the academic rabbithole that they think eg “car” and "cdr” are intuitive names for “retrieve the first element of a list” and “retrieve the…
Car and crd is lisp and from the 60:ies, basically. You can liken them to assembly instructions because that's kinda sorta why they're named like that.
I still stand by what I said about them.
If you write Rust for 1-2 years, I bet you you'll come to look at programming in those languages completely differently. I have a very high carry over, going in to Rust from those languages.