On Wednesday, 17 January 2018 at 19:43:03 UTC, Manu wrote:
> I quite like C++ explicit unpacking (using ...), and I wouldn't be upset to
> see that appear here too.

FWIW C++17 has structured binding:
http://en.cppreference.com/w/cpp/language/structured_binding

auto [x,y] = f()

On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:
> On 14.01.2018 19:14, Timothee Cour wrote:
>> actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
>> is that? (at least for std.typecons.tuple)
>> maybe worth mentioning that in the DIP (with rationale)
>
> It's inherited from C, where all struct instances have size at least 1. (Such that each of them has a distinct address.)

Inherited from C++. In C empty structs have size 0. This caused me all sorts of problems when importing C headers from C++ in funky codebases.

foo.c:
#include <stdio.h>

struct Foo {};

int main() {
    printf("%zu\n", sizeof(struct Foo));
    return 0;
}


% clear && gcc foo.c && ./a.out
0

% clear && gcc -xc++ foo.c && ./a.out
1


Atila

On Tuesday, 23 January 2018 at 11:04:33 UTC, Atila Neves wrote:
> On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:
>> On 14.01.2018 19:14, Timothee Cour wrote:
>>> actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
>>> is that? (at least for std.typecons.tuple)
>>> maybe worth mentioning that in the DIP (with rationale)
>>
>> It's inherited from C, where all struct instances have size at least 1. (Such that each of them has a distinct address.)
>
> Inherited from C++. In C empty structs have size 0. This caused me all sorts of problems when importing C headers from C++ in funky codebases.
>
> foo.c:
> #include <stdio.h>
>
> struct Foo {};
>
> int main() {
>     printf("%zu\n", sizeof(struct Foo));
>     return 0;
> }
>
>
> % clear && gcc foo.c && ./a.out
> 0
>
> % clear && gcc -xc++ foo.c && ./a.out
> 1
>
>
> Atila

AFAIR the ISO C standard does not allow empty structs (as they would have no meaning). If you use the warnings as errors option, it won't compile:

<source>:3:8: error: struct has no members [-Werror=pedantic]
 struct Foo {};
        ^~~

On Tuesday, 23 January 2018 at 14:58:07 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 23 January 2018 at 11:04:33 UTC, Atila Neves wrote:
>> On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:
>>> On 14.01.2018 19:14, Timothee Cour wrote:
>>>> actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
>>>> is that? (at least for std.typecons.tuple)
>>>> maybe worth mentioning that in the DIP (with rationale)
>>>
>>> It's inherited from C, where all struct instances have size at least 1. (Such that each of them has a distinct address.)
>>
>> Inherited from C++. In C empty structs have size 0. This caused me all sorts of problems when importing C headers from C++ in funky codebases.
>>
>> foo.c:
>> #include <stdio.h>
>>
>> struct Foo {};
>>
>> int main() {
>>     printf("%zu\n", sizeof(struct Foo));
>>     return 0;
>> }
>>
>>
>> % clear && gcc foo.c && ./a.out
>> 0
>>
>> % clear && gcc -xc++ foo.c && ./a.out
>> 1
>>
>>
>> Atila
>
> AFAIR the ISO C standard does not allow empty structs (as they would have no meaning). If you use the warnings as errors option, it won't compile:
>
> <source>:3:8: error: struct has no members [-Werror=pedantic]
>  struct Foo {};
>         ^~~

That's a warning treated as error. I checked and it seems that you're right about the C standard, although in practice compilers seem to accept empty structs. I knew that in C++ it's explicit that empty classes have size 1. Live and learn.

Atila

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
>
>
> This DIP aims to make code like the following valid D:
>
> ---
> auto (a, b) = (1, 2);
> (int a, int b) = (1, 2);
> ---
>
> ---
> foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
> {
>     writeln(sum, " ", diff);
> }
> /+ prints:
> 3 -1
> 7 1
> +/
> ---
>
> Before going ahead with it, I'd like some preliminary community input:
>
> - I'm not yet completely satisfied with the DIP.
>   (See section "Limitations".)
>   Please let me know suggestions or further concerns you might have.
>
>
> - There are good example use cases missing. While I'm confident I could
>   invent a few of them given a little time, I thought maybe I can
>   expedite the process and make the point more convincingly by asking
>   for use cases you encountered in your own code. The DIP already
>   contains an example due to bearophile.
>
>
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com


My small contribution to this:

https://github.com/dlang/dmd/pull/7813
https://github.com/dlang/dlang.org/pull/2151

Comma expressions will soon (2.079) be fully gone from the language and they can now finally be re-purposed for tuples.

On 01/12/2018 11:44 PM, Timon Gehr wrote:
> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
> 
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

Pardon me if things have been said already, can't really read through all the thread.

- - Regarding underscore as placeholder.

https://issues.dlang.org/show_bug.cgi?id=13522

- - Regarding the "limitation"

Maybe you want some auto-packing feature there? Doesn't seem too bad,
we could come up with sth. when this turns out to become a common
nuisance.
Have you considered to lower (1, 2, 3)[0 .. 2] to tuple(tuple(1, 2,
3)[0 .. 2]) or using a non-std.typecons tuple where slicing does not
expand?

- - closed tuples?

The reference to std.typecons.tuple implies contiguous struct memory
layout (closed tuples).
This is a bit subtle for unpacking assignments which lower to

AliasSeq!(x, y) = tuple(y, x)[];

so on the left-hand side of an assignment, the syntax refers to a
non-contiguous (open) tuple.

Declarations like

auto (a, b) = (1, 2);

also seem to declare an open tuple (non-contiguous memory).

I assume that unpacking function arguments behaves similarly, i.e. on ABI level, each argument is passed separately.


Overall looks really good. I think that would make for a great addition to the language.

- -Martin

On 01/14/2018 07:41 PM, Timothee Cour wrote:
> Should definitely be mentioned in the DIP to open that up for discussion;
> it breaks assumptions like sizeof(Tuple)=sum_i : tuple (sizeof(Ti));

That doesn't hold for all cases anyhow, as it seems were talking about closed tuples that are contiguous in memory and follow struct layout and alignment rules.

On 01/14/2018 12:21 AM, Timon Gehr wrote:
>> what would be the equivalent of this ?
>> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> 
> It would continue to work the same way.
> 
> I did consider adding a proposal for built-in named tuple syntax:
> 
> writeln((x: 2, y: 3, z: 4).y);
> 
> (int a, double b) t = (a: 1, b: 2.0);
> int x = t.a;
> double y = t.b;

Tuples are anonymous bundles, when you want a product type with field names use a struct.

On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:
> On 01/14/2018 12:21 AM, Timon Gehr wrote:
> >> what would be the equivalent of this ?
> >> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> >
> > It would continue to work the same way.
> >
> > I did consider adding a proposal for built-in named tuple syntax:
> >
> > writeln((x: 2, y: 3, z: 4).y);
> >
> > (int a, double b) t = (a: 1, b: 2.0);
> > int x = t.a;
> > double y = t.b;
>
> Tuples are anonymous bundles, when you want a product type with field names use a struct.

That's not necessarily unreasonable, but std.typecons.Tuple is frequently used as a convenient way to return a group of values, and the trend has been towards using named values, because those are easier to deal with as return values, because they're somewhat self-documenting at that point, and they're less error-prone. So, if we're talking about adding more complete tuples to the language, if they don't have support for names, you then have the problem of whether it's better to use the built-in tuples or something like std.typecons.Tuple with named values, and there's a pretty strong argument at that point that it's better to use the named tuples and lose whatever benefits the built-in tuples might provide, because the named tuples result in more maintainable code.

- Jonathan M Davis

On Fri, Feb 16, 2018 at 01:16:13PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:
> > On 01/14/2018 12:21 AM, Timon Gehr wrote:
> > >> what would be the equivalent of this ?
> > >> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> > >
> > > It would continue to work the same way.
> > >
> > > I did consider adding a proposal for built-in named tuple syntax:
> > >
> > > writeln((x: 2, y: 3, z: 4).y);
> > >
> > > (int a, double b) t = (a: 1, b: 2.0);
> > > int x = t.a;
> > > double y = t.b;
> >
> > Tuples are anonymous bundles, when you want a product type with field names use a struct.
> 
> That's not necessarily unreasonable, but std.typecons.Tuple is frequently used as a convenient way to return a group of values, and the trend has been towards using named values, because those are easier to deal with as return values, because they're somewhat self-documenting at that point, and they're less error-prone. So, if we're talking about adding more complete tuples to the language, if they don't have support for names, you then have the problem of whether it's better to use the built-in tuples or something like std.typecons.Tuple with named values, and there's a pretty strong argument at that point that it's better to use the named tuples and lose whatever benefits the built-in tuples might provide, because the named tuples result in more maintainable code.
[...]

Tuples with named fields are essentially anonymous structs.  If we had those, 60% of what this DIP addresses would already have been solved. Cf.:

	https://forum.dlang.org/post/kfbnuc$1cro$1@digitalmars.com


T

-- 
Ignorance is bliss... until you suffer the consequences!