@eyalroth - Just for reference, Rust is absolutely chock-full of special traits, and it doesn’t seem to bother anyone. Just the opposite–expressing things via special traits makes different features more regular, at least in Rust.
The problem with DelayedInit wasn’t that it was special, it was that it was hard to use correctly. Dynamic works fine–not used much, but it’s fine. StringContext works fine as a dispatcher for string interpolation.
I’m not entirely sure what do you mean by “more regular”. To me, the more special objects a language has the less regular it is, because those special objects seem weaker than keywords, and are more subjected to changes in the future. They are not seen as strict – regular – rules.
I’m honestly not sure what is the problem with DelayedInit, as it wasn’t explicitly explained (as I’ve discussed here). What I was able to interpret from the previous discussions is that they are “surprising”, and that this may partly stem from them being a special trait instead of a more regular / established mechanism.
The same goes for StringContext, which I found to be quite odd when I first used it (to implement custom JSON parsing just like in the documentation example). It seemed to me as quite the irregular feature, that was not very intuitive to learn. I think the case of implicit conversations has a much grater potential for confusion than string interpolations, so I’d prefer them to not be encoded via special objects.
I understand the general notion of this decision, but I don’t think this is an independent thread. The discussion is not about DelayedInit nor StringContext. Those were used as examples in the argument for or against special traits, which I believe is a relevant topic to this proposal.
I’d appreciate if this counter-argument for the current design would be considered when making a decision on this proposal.
Consider editing your original post to — still within reasonable limits of concision — expand on this point a little more, if you feel that it is one of the few most important considerations that the committee needs to hear. It’s fine to include a link to further specifics for those interested.
The overall goal here is to produce a main topic that committee members can reasonably read and digest at the end of the one-month feedback period.
I’m sorry to make an example of you and Rex in this instance, but we need to make a change in how we are doing this, going forward, and we need to start somewhere.
Yes, they’re weaker in a sense, but they also get to take advantage of features that allow you to deal with traits.
In Rust, for example, if you want to use + you need to implement the Add trait. The compiler handles converting + to the function name.
This works fine. And it means that you can use your usual tricks to get trait support.
So as long as it’s kind of trait-like (i.e. a property of the type), why not make it a trait?
I think it’s reasonable to have a side-discussion about the virtue or vice or simple subjective preference of having special traits that indicate some sort of special handling by the compiler.