Proposal: Object/?? Destruction

sarn sarn at theartofmachinery.com
Mon Oct 16 23:29:46 UTC 2017


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/ecwfiderxbfqzjcyymkg@forum.dlang.org
https://forum.dlang.org/thread/ihsmxiplprxwlqkgwswc@forum.dlang.org
https://forum.dlang.org/thread/qsayoktyffczskrnmgxu@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).


More information about the Digitalmars-d mailing list