January 17, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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() |
January 23, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 |
January 23, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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 {};
^~~
|
January 23, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Petar Kirov [ZombineDev] | 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
|
January 31, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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. |
February 16, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr Attachments: | 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 |
February 16, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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.
|
February 16, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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.
|
February 16, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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
|
February 16, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
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! |
Copyright © 1999-2021 by the D Language Foundation