Rant after trying Rust a bit

[Jonathan M Davis via Digitalmars-d]

On Sunday, 26 July 2015 at 16:39:23 UTC, jmh530 wrote:
> My biggest problem with your point about including everything 
> in the top-level is that if you make a change to the 
> constraints in the bottom level then you have to remember to 
> make the changes everywhere else.

Well, that's pretty much exactly why Walter is trying to say that 
it's the same problem as checked exceptions. Changing something 
lower in the chain forces you to change everything higher in the 
chain - and often, stuff higher in the chain isn't written by the 
same person or organization as the stuff lower in the chain. If 
we did what some folks are suggesting and make it so that the 
compiler gave an error if a template constraint failed to cover 
all of its sub-constraints (which would probably require using 
concepts), then changing the function lower in the chain would 
outright break all of the code higher in the chain, making it 
even more like checked exceptions. But even without that 
enforcement, we have a maintenance problem if the lower level 
constraints need to be propagated. If the constraints almost 
never change, then it won't necessarily be a big deal, but as 
code is updated and improved, then it could be a much bigger one.

For a publicly available library like Phobos, the solution may 
simply be that the template constraints of functions in the 
public API can only ever be made less strict rather than more 
strict so that they don't stop working with any existing code or 
cause other functions up the chain to have to tighten their 
template constraints as well. But with all of the inference and 
conditional compilation that you get in D code, maybe even 
reducing the restrictions would cause problems in some cases - 
especially if something like __traits(compiles, ...) is used in 
template constraints, because that change could potentially make 
it so that overloads start conflicting (or just change) in higher 
level functions and thus break code. Though given how much you 
can do with metaprogramming in D, pretty soon changing _anything_ 
risks breaking code, so I don't know how much we should really 
worry about that. If you're doing stuff that involves that much 
type introspection, the odds of your code breaking with changes 
to the libraries you're using are high enough that it's probably 
not reasonable to expect that it won't break anyway.

In any case, I suppose that we'll just have to wait and see how 
much a problem this will really become, but I don't think 
attempting to keep the higher level constraints in line with the 
lower level ones is as bad as doing something like concepts where 
it's forced. At least with what we have, the worst you normally 
get is an error inside of a template instead of at the outer 
template constraint. And if someone doesn't want to try and 
propagate the template constraints, they don't have to - they 
just then have to deal with error messages being inside of the 
templated function (or inside of templated functions that gets 
called by that function - either directly or indirectly) - and if 
we improve the error messages enough, then that won't be so bad. 
So, we have a potential maintenance problem here, but it's not 
one that's generally going to be from broken code so much as 
reporting the error at a point other than the one where folks 
want to see it.

- Jonathan M Davis