Proposal: Object/?? Destruction

[Q. Schroll]

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