On 5/6/2023 8:55 AM, Quirin Schroll wrote:
> I have a very stupid question now: Why does a minor grammar change require a DIP? How do people determine what is an enhancement and what requires a DIP?

It's not a stupid question at all.

The reason is, it is definitely non-trivial, it will impact a lot of code with deprecations, people will want a strong explanation of why this is worthwhile, and enable a wider audience to look for risks and flaws.

At a first reading, this looks like a worthwhile endeavor.

But the thing is, what you've written is already pretty close to being a DIP. You've already done the hard part.

One question: can this peacefully coexist with the existing syntax, before we push it with a deprecation?

On 5/6/2023 8:55 AM, Quirin Schroll wrote:
> For the record: I’ve objected to parentheses for tuples from the beginning. Parentheses are for grouping, not for constructing. My take on the tuples front was to look at static arrays as the special case of tuples that are homogeneous (the same type iterated), and generalize them for heterogeneous components: `int[2]` is a shorthand for `[int, int]`; and `[int, string]` is a heterogeneous tuple. You build such a tuple like you build an array: `[1, "abc"]`. Indexing with a run-time index is supported by Design by Introspection: A `[int, immutable int]` can give you `ref const(int)` access, a `[int, long]` can give you `long` access by value, but no `ref` access.

I'd like Timon Gehr to weigh in on this!

This is written with Markdown, which my newsreader doesn't recognize. Here's a more readable link:

https://forum.dlang.org/thread/lxcjsxxamwwtkdpmjhze@forum.dlang.org

On 5/7/23 02:16, Walter Bright wrote:
> On 5/6/2023 8:55 AM, Quirin Schroll wrote:
>> For the record: I’ve objected to parentheses for tuples from the beginning. Parentheses are for grouping, not for constructing. My take on the tuples front was to look at static arrays as the special case of tuples that are homogeneous (the same type iterated), and generalize them for heterogeneous components: `int[2]` is a shorthand for `[int, int]`; and `[int, string]` is a heterogeneous tuple. You build such a tuple like you build an array: `[1, "abc"]`. Indexing with a run-time index is supported by Design by Introspection: A `[int, immutable int]` can give you `ref const(int)` access, a `[int, long]` can give you `long` access by value, but no `ref` access.
> 
> I'd like Timon Gehr to weigh in on this!

There is no conflict between the two features in the first place.

I am in favor of allowing types in arbitrary expressions, as well as parentheses within types. My own D frontend already had a proof of concept implementation of that. [1]

It also does not affect anything in my fork of DMD that already has some tuple support [2]: in particular a single-element tuple is indicated with a trailing comma, like `(int,) x = (1,);`. Having `(int) x = (1);` mean `int x = 1` would be fully consistent and unsurprising.

[1] https://github.com/tgehr/d-compiler/
[2] https://github.com/tgehr/dmd/tree/tuple-syntax


About the attack on standard tuple syntax with parentheses: Having `T[2]` be a tuple type `[T,T]` is one of those things that initially sound good enough on paper until you actually examine the existing array semantics that D already has and try to square them with tuple semantics. It does not work at all. D would need to break arrays. It's a pipe dream.

It's not that I don't get that fixed-length arrays and tuples (and variable-length-arrays and argument lists etc) can be fully unified in principle (I have done it in some of my own languages [3]), it's just that it cannot really be done well as an afterthought.

[3] https://github.com/eth-sri/silq

def rev[τ:*,n:!ℕ](xs:τ^n){
    for i in 0..n div 2{
        (xs[i],xs[n-1-i]):=(xs[n-1-i],xs[i])
    }
    return xs;
}

def main(){
    t:=(1,(2,3)): !ℕ×!ℕ^2;
    a:=(1,2,4,3): !ℕ^4;
    assert(rev(a)=(3,4,2,1));
    assert(rev(a,)=(a,));
    assert(rev(1,2,3)=(3,2,1));

    n:=2+measure(H(0:𝔹)); // (n is 2 or 3 with equal probability)
    b:=vector(n,0:!ℕ);
    for i in 0..n{ b[i]=i; }
    assert(rev(rev(b))=b);
}

On 5/6/23 17:55, Quirin Schroll wrote:
> 
> For the record: I’ve objected to parentheses for tuples from the beginning. Parentheses are for grouping, not for constructing.

',' is the constructor...

On 5/4/2023 9:34 PM, Paul Backus wrote:
> On Friday, 5 May 2023 at 02:30:32 UTC, Basile B. wrote:
>> Wouldn't making `ref` a TypeCtor solve the issue more simply ?
> 
> The main problem with making `ref` a TypeCtor is that it would allow semantically-invalid types like `ref(int)[]` and `Tuple!(ref(int), ref(int))` to parse.

Yeah, arrays of references won't work.

On 5/6/23 5:50 PM, Walter Bright wrote:
> This is written with Markdown, which my newsreader doesn't recognize. Here's a more readable link:
> 
> https://forum.dlang.org/thread/lxcjsxxamwwtkdpmjhze@forum.dlang.org

If you happen to be using Thunderbird, I made an add-on that renders Markdown messages pretty well.

https://addons.thunderbird.net/en-US/thunderbird/addon/render-markdown-messages/?src=search

On Sunday, 7 May 2023 at 07:35:22 UTC, Timon Gehr wrote:
> [..]
>
> Having `T[2]` be a tuple type `[T,T]` is one of those things that initially sound good enough on paper until you actually examine the existing array semantics that D already has and try to square them with tuple semantics. It does not work at all. D would need to break arrays. It's a pipe dream.
>

Can you explain in more detail which parts of the language make the unification impossible currently? Or to phrase the question differently, in a hypothetical D3 language what (breaking) changes we would need to do relative to D2 to make this possible?