On Thursday, 25 June 2015 at 20:54:38 UTC, Walter Bright wrote:
Please, no code breakage because of renaming.
Well, the whole idea behind Adam's proposal to make functions like toLower return a struct which is a lazy range but uses alias this to do eager allocation is to allow us to switch to lazy by default with these functions without breaking code, because when you assigned it to a string, it would allocate just like it did before. So, in theory, there wouldn't be any code breakage.
However, as appealing as I find the idea of silently converting eager functions into lazy functions without breaking code, I'm not at all convinced that it will really work and that it won't break code. As long as the type string is used explicitly in the caller, it should be fine, but with enough uses of auto and interacting with other templated functions that do who-knows-what, I'm no sure that it's actually going to do the implicit conversion to string in all of the cases that it really needs to (e.g. the resulting range type would fail isSomeString, and if the function that you passed it to required isSomeString via its template constraint but didn't have an overload for generic ranges of dchar, it would fail to compile).
In general, implicit conversions are incredibly dangerous with generic code - particularly with regards to template constraints, because it's trivial to have a type which implicitly converts, but if the templated function doesn't actually force the conversion, then the function might not actually compile with the original type, and even if it does, you could get some weird, hybrid behavior where some of the operations in the function end up being done on the original type and some end up being done on the result of alias this. So, we need to be _very_ careful when using alias this in generic code.
So, while I do like Adam's idea in principle - and it shows off D's power nicely - I think that the fact that we're talking about combining alias this and generic code is a very risky proposition. It probably will work in _almost_ all cases without breaking any code, but I seriously question that it will work in _all_ cases.
- Jonathan M Davis
