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)
On Sun, Jan 14, 2018 at 8:18 AM, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 14.01.2018 15:55, Q. Schroll wrote: >> >> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: >>> >>> [...] >>> This DIP aims to make code like the following valid D: >>> >>> --- >>> auto (a, b) = (1, 2); >>> (int a, int b) = (1, 2); >>> --- >>> [...] >> >> >> How is (1, 2) different from [1, 2] (static array)? > > > The first is a tuple, the second is a static array. This distinction exists > already, it is not proposed in this DIP. > > I.e., you could just as well ask "How is tuple(1, 2) different from [1, 2] > (static array)?". A (probably non-exhaustive) answer is that dynamic arrays > have a 'ptr' property; slicing a static array will produce a dynamic array; > tuples alias this to an 'expand' property that gives the components as an > AliasSeq; an empty tuple will take up 1 byte of space in a struct/class, but > an empty static array will not; empty static arrays have an element type, > 'void' is allowed as the element type of an empty static array; array > literals are _dynamic_ arrays by default, enforcing homogeneous element > types, while tuple literals give you heterogeneous _tuples_, ... > > None of this has much to do with the DIP though. > >> It makes no sense to me to have both and probably a bunch of conversion >> rules/functions. >> ... > > > The DIP proposes no new conversion rules, nor does it _introduce_ tuples. > You'll need to complain about the status quo elsewhere; blaming the DIP for > it makes no sense. > >> Why don't you consider extending (type-homogeneous) static arrays to >> (finite type enumerated) tuples? > > > Because tuples and arrays have significant differences as outlined above and > tuple literal syntax is essentially useless if it needs to be accompanied by > explicit type casts or annotations on every use. It's better to not add > tuple syntax at all than to overload square brackets in this ad-hoc manner. > Calling 'tuple(1, 2.0)' is less of a hassle than writing cast([int, > double])[1, 2.0]. This is just not good language design. > >> It solves >> - 1-tuples > > > There is already a solution. > >> - comma operator vs. tuple literal > > > The comma operator is gone. > >> instantly. > > > I think it introduces more problems than it solves. > >> You'd have T[n] as an alias for the tuple type consisting of n objects of >> type T. >> ... > > > So whether or not a tuple is instead a static array (according to the > differences above) depends on whether or not the types happen to be > homogeneous? > > I do understand very well the superficial aesthetic appeal, but this is > unfortunately just not a workable approach. > >> I've written something about that here: >> https://forum.dlang.org/post/wwgwwepihklttnqgh...@forum.dlang.org > > > (The DIP links to that thread.) > >> (sorry for my bad English in that post) >> ... > > > The English is fine. > >> The main reason I'd vote against the DIP: Parenthesis should only be used >> for operator precedence and function calls. > > > You do realize that this translates to "just because"? > (That, and you forgot about template instantiation, type constructor/typeof > application, if/for/while/switch/scope/... statements, type casts, basic > type constructor/new calls, ... (list wildly non-exhaustive).)
