Overall quite good, just a couple of tweaks I'd prefer to have to make everyone's lives easier (such as custom runtime writers).



Proposal 3: Built-in tuple types and literals

Why are you putting it into object.d?

Its big enough as it is, and these types can be copied wholesale.

Putting them in a dedicated module would be a much better choice.



Proposal 6: Placeholder name _

This is guaranteed to break code, its going to have to wait for an edition to execute. No need to do it in two stages then.

This is a well written DIP. Congratulations!

The forward range tuple is pretty cool.

Let's move forward with this.

bearophile's example uses `_` as a placeholder, but I don't see it mentioned in the rest of the DIP?

For the example:
```
auto arr = [tuple(1, "2"), tuple(3, "4"), tuple(5, "6")];

foreach((x, y); arr) {
    writeln(x, " ", y); // "1 2\n3 4\n5 6"
}

foreach((int x, string y); arr) {
    writeln(x, " ", y);// "1 2\n3 4\n5 6"
}
```

shouldn't there be a trailing \n after the 6?

On 7/27/25 08:31, Walter Bright wrote:
> This is a well written DIP. Congratulations!
> 
> The forward range tuple is pretty cool.
> 
> Let's move forward with this.
> 
> bearophile's example uses `_` as a placeholder, but I don't see it mentioned in the rest of the DIP?
> ...

He had used it as a placeholder by convention, but it's just a valid identifier. It would not be possible to use it for two distinct variables in the same scope.

I.e., you can do:

```d
int _ = 2;
```

But not:

```d
int _ = 3;
int _ = 4;
```

Which would work with a true placeholder.

> For the example:
> ```
> auto arr = [tuple(1, "2"), tuple(3, "4"), tuple(5, "6")];
> 
> foreach((x, y); arr) {
>      writeln(x, " ", y); // "1 2\n3 4\n5 6"
> }
> 
> foreach((int x, string y); arr) {
>      writeln(x, " ", y);// "1 2\n3 4\n5 6"
> }
> ```
> 
> shouldn't there be a trailing \n after the 6?

Yes.

On 7/25/25 15:42, Richard (Rikki) Andrew Cattermole wrote:
> Overall quite good, just a couple of tweaks I'd prefer to have to make everyone's lives easier (such as custom runtime writers).
> ...

I think you were looking at the wrong document, seems you were reading my old draft that had a bigger scope. Neither of these features are proposed by the DIP.

That said:

> 
> 
> Proposal 3: Built-in tuple types and literals
> 
> Why are you putting it into object.d?
> 
> Its big enough as it is, and these types can be copied wholesale.
> 
> Putting them in a dedicated module would be a much better choice.
> ...
> 

Something like `core.internal.tuple` or similar will probably be better.

> 
> Proposal 6: Placeholder name _
> 
> This is guaranteed to break code, its going to have to wait for an edition to execute. No need to do it in two stages then.
> 

Yes. This is why this is not part of this DIP.

You are so right, I looked at the wrong document.

In that case I'd like to point out:

1. The wording around ``ref`` and ``out`` could be improved. The behavior of each should be matching and it does seem to read as such, even if it isn't in the same paragraph.

2. Moving elements should be in DIP even if implementation doesn't support it. I don't think anything special needs to be done here. My understanding is the compiler should be seeing the VarDeclaration -> VarDeclaration assignment and handle it normally.

On 01/08/2025 10:08 PM, Nick Treleaven wrote:
> On Sunday, 27 July 2025 at 21:52:15 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> 2. Moving elements should be in DIP even if implementation doesn't support it. I don't think anything special needs to be done here. My understanding is the compiler should be seeing the VarDeclaration -> VarDeclaration assignment and handle it normally.
> 
> I think you are asking for something special:
> 
> ```d
>      T a, b;
>      alias seq = AliasSeq!(a, b);
>      // auto (x, y) = a;
>      auto x = a[0];
>      auto y = a[1];
> ```
> 
> `a[0]` and `a[1]` are not moved by the lowered code.
> 
> Do you have an example where there should be a move?

You are getting to what I was thinking, there is no reason to mention copying or moving. Its defined behavior elsewhere.