On Tuesday, 12 July 2016 at 17:55:22 UTC, Ethan Watson wrote:
However, this goes to prove my point. In both cases, it's a bunch of legwork just to get to a true_type or a false_type.
Ok, I don't have much trouble with it. I usually want to abstract such tests into concepts and stuff them in to a library and only use "has_equality<T>"...
covered by the standards, it's a whole bunch of near-esoteric work you'll need to understand to get to that point.
Well, the problem is that there is a lot of out-dated advice out there for how to do template programming in C++ that is rather convoluted. But there are some fairly simple patterns to use for both testing functionality and disabling functionality.
In my view the major advantage D has is in being able to disable struct fields with static if, I haven't found a simple way to do that in C++.
Whereas in D, you can do the same thing with an is() statement.
Sure, you can always add special-cased builtins, but if you can express it in a relatively simple core inference engine then you can just add it with syntactical sugar and avoid all the special casing in analysis stages. Lowering to the core language should always be the preferred way to extend the language.
So from a language design perspective it is sound to only implement the core language and enable library solutions. If that leads to boiler plate you need to reconsider the abstraction mechanisms you provide and not necessarily add lots of special cased functionality.
The inference engine that C++ templates provide is convoluted, no doubt about it, but that is a past mistake. Adding special casing isn't the right answer to rectifying the mistake.
Did you see my DConf talk? Do you know that DMD uses mslink for 64 bit builds, and we use the Xbox One version of mslink to get Xbox One compatibility? It seems to me you'll understand where I'm coming from better if you look at what I've already put out there.
I haven't seen any of the 2016 DConf talks.
