What can/can't we do with Rust which already supports operator overloading, macros, and (to some extent) const fn?
My primary interest is in the core language design which will allow 3rd party crates to implement necessary features without baking them into rustc itself, although the authors did point out likely limitations of the embedded DSL approach.
(Sorry I haven't gone through the document myself yet...)
I just skimmed the documents, and this looks like a really, really niche application that hasn't had time to mature yet. Not something I'd want to see in core rust. It should probably be in a crate somewhere first.
As for what we can/can't do, about the only thing I can think of is the orphan rules might prevent you from creating a generic crate that defines some traits that others are then expected to implement on the primitive types. However, if you're willing to spend the time to implement the traits on all of the primitive types, then you could distribute a crate that does all of this for you.
Exactly. Swift has a history of baking heavy functionality in the language, for the record. Its serialization infrastructure is implemented as a compiler-built-in special protocol (~= trait), which is not very well configurable and is a complete pain to use compared to serde_derive. So I don't think Rust should take this sort of inspiration from Swift.
Comparing this with Swift's serialization feature is not a good argument. Saying "Swift has it, so we should have it too!" is just as wrong as saying "Swift has it, so it must be a bad idea!".
So is putting words in others' mouth. I wasn't asserting that everything Swift has is bad. What I think is bad is making large, complex features into language built-ins, which could have been written as a library.
In particular he seems to be asking if there are any small modifications to core rust could be made that would make making it differentiable vastly easier, and the answer is probably that someone's going to have to start making the attempt to find out.