On 6/24/15 9:50 AM, Vladimir Panteleev wrote:
On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
We disagreed on this on irc, but I ask you to consider the following
which limits the code breakage a lot more than my first proposal in chat:
[...]
Some thoughts:
- I think the implementation is better done through composition (i.e. a
function that takes any range, and returns a type that works like that
range but also allows implicit conversion to string. Not sure how
feasible this is, maybe multiple alias this will help.
- On the performance side, one point is that this grows the size of the
struct by two machine words (string's .ptr and .length). This type is
likely to be passed by value through function parameters, too.
- Another perf. issue is that this introduces additional cost every time
the implicit conversion to string is done (you need to at least check if
the string value has been calculated).
I think these points are not quite as bad as you think:
1. Any code that was written to use the string version is currently
passing a string for the extension. Only provide a cached conversion to
string if that is the case (i.e. you have 2 strings passed in), and
we'll be fine for existing code. Store the cached string into one of the
two stored ranges. Don't even bother allowing conversion from non-string
ranges to a string, just don't compile. This solves the space problem.
2. Code that is using the string version can call array, or can
specifically say "string x = ..." instead of "auto x = ..." to avoid
extra checks if they want to squeeze out that little test instruction. I
don't see why we should care about an extra check for code that is
deprecated or undesirable, and I don't see how the extra check is that
bad either.
I really like Adam's idea. A lot.
-Steve
