On Monday, 16 October 2017 at 23:29:46 UTC, sarn wrote:
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?
Yes. No weirdness is being introduced that is not there already.
Maybe I have overseen something; I will not give you or anyone
else a guarantee for the solution to work perfectly. I've thought
through the case very long.
An open question is allowing partly const/immutable/shared (cis)
tuples. As for now, I didn't care. Even c/i/s-homogeneus tuples
(the tuple is c/i/s as a whole or not) would be a win in my
opinion. One rarely needs tuples with one component immutable but
the other one mutable. This is what a named struct is for. On the
other hand, I don't know of any issues having a to partly c/i/s
std.typecons.Tuple.
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.
Right conclusion with insufficient explanation. [1, 3.14] is a
static array in the first place. It occupies a fully inferred
template parameter position. I don't know the implementation, but
every time I tested, it behaves as if typeof(expr) is being used
after the bang to set the template argument manually (even for
Voldemort types etc. where typeof is sometimes impossible due to
missing frame pointers). typeof returns "dynamic array of T" for
array literals. This is all the weirdness going on here. It is
present today and would remain present if you interpret [1, 3.14]
as a tuple.
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.
The only exception is typeof and (therefore, I don't know...)
template inference.
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).
You don't have to as long as you don't want to support tuples
explicitly; otherwise you have to. If you have a void f(int,
double), you cannot plug in [1, 3.14]. You can use some expand to
do it. You wouldn't want to either. If you have something
*explicitly typed* as a tuple, e.g.
[int, double] tup = [1, 3.14];
you can make the call f(tup) because auto expansion does its job.
This is the use case. If you have void f([int, double]), you can
plug in tuple literals.
If you use a tuple literal for a function call, the compiler will
search for explicit matches for tuples. If it cannot find any,
conversion to a dynamic array happens.
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.
Yes. It would be converted in almost all cases -- the same with
static arrays -- because the best match doesn't occur very often
and typeof never returns static arrays or tuples for literals.
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
This is completely unrelated. Concerning the issues people have
with (..) => { .. }, I've filed an enhancement request to
deprecate it in that specific case:
https://issues.dlang.org/show_bug.cgi?id=17951
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).
It's not adding any magic to [] that isn't there already. The
other proposals are adding magic to (). Even some mathematicians
use chevrons (angle brackets) for tuples as they see parentheses
as indicators of precedence. I'd vote against angle brackets, see
C++ templates for reasons. Logicians and haskellers even don't
need parentheses for function calls.
Could I convince you?
