On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether [1,
2] is a tuple literal or a dynamic array literal.
It would be a tuple if that's the best match, otherwise
conversion to int[] is tried.
...
You'd need to use a prefix or something to the bracket syntax.
[snip]
I just argued, you don't!
But have you thought through all the implications?
Take this code:
void main(string[] args)
{
import std.stdio : writeln;
writeln([1, 3.14]);
}
As you're probably 100% aware, this is totally valid D code
today. [1, 3.14] becomes a double[] because 1 gets converted to
a double. If this kind of behaviour changes, code will break, so
you'll need a bunch of exceptions to the "it would be a tuple if
that's the best match" rule. Also, for the same backwards
compatibility reasons, it would be impractical in most cases to
add any tuple overloads to most existing standard library
functions that currently accept slices or arrays, but presumably
new functions would be meant to take advantage of the new syntax
(else there wouldn't be much point creating a new syntax).
So, a literal like [1, 3.14] would basically be a tuple, but
would be converted to double[] in a bunch of special cases for
historical reasons.
If you're not sure if this is really a problem, take a look at
the confusion caused by the magic in {} syntax:
https://forum.dlang.org/thread/ecwfiderxbfqzjcyy...@forum.dlang.org
https://forum.dlang.org/thread/ihsmxiplprxwlqkgw...@forum.dlang.org
https://forum.dlang.org/thread/qsayoktyffczskrnm...@forum.dlang.org
To be totally honest, I still don't see what's wrong with just
creating a new bracket syntax, instead of adding more magic to []
(or () for that matter).
