22-Mar-2013 15:25, bearophile пишет:
> Dmitry Olshansky:
>
>>> auto (lof, loa) = ...;
>>>
>>> In Haskell, Scala, Python, F#, etc, the semantics and syntax are
>>> similar.
>>>
>>
>> I'd hate any solution that distances ordinary structs, library tuples
>> and fixed-sized arrays. If anything these should be trivially
>> substitutable where makes sense.
>
> In Bugzilla I suggested that syntax for arrays too, I'd like that:
>
> int[2] data = [10, 20];
> auto (a, b) = data;
>
>
> Regarding tuples and structs, Tuples are implemented as structs, so
> forbidding struct unpacking is probably more work than not doing it. On
> the other hand structs and tuples are not exactly the same thing,
> despite one is implemented with the other.

What the heck this paragraph supposed to mean? Sorry I can't get the message out of it.

What I think is that unpacking both tuples, structs and _fixed_ arrays has to be done the same way, period. That way has to be easy, concise and non error prone. Otherwise I'd call it all a failure.

Dynamic arrays are the different beasts we may postpone decision on whether unpacking these in the same vein makes sense.

>
>> I even had proposal to about same effect, but it was ignored. Among
>> other things it replace .tupleof with more general destructuring
>> facility.
>
> I don't want to use ".tupleof" to unpack a Tuple. Because it's a very
> commonly done operation, so it needs a short syntax.
>

What I've meant is to add easily controllable way to slice up fields from structs as tuples (pretty much as .tupleof is doing but more fine-grained) see:

struct P { int x; int y; double d; }

P p = P(2, 5, 5.6);

auto (x,y) = p.{x, y};  // + your unpacking

p.{x,y} = p.{y,x}; // anmd many more short-hand things are possible

Nested stuff is also no problem:

struct J{ P a; P b; double r; }

J j = ....;

auto (first, second, last) = j.{a, b.{y}, r};
static assert(typeof(first) == P);
static assert(typeof(second) == int);
static assert(typeof(last) == double);

Same with any nesting depth, b.{x,y} has type (int,int) as internal tuple or Tuple!(int, int) as in Phobos but it'd better be in druntime then.

.tupleof is then done as trivial default:

auto unpacked = j.{};
static assert(typeof(unpacked) == Tuple!(P, P, double));


-- 
Dmitry Olshansky

On Friday, 22 March 2013 at 11:14:47 UTC, Dmitry Olshansky wrote:
> I'd hate any solution that distances ordinary structs, library tuples and fixed-sized arrays.

Are struct/tuples similar to fixed-sized array?
I thought that both are different because you can select which element you access at runtime in an array, but usually this is not possible with structs and tuples where this is selected at compile time and then I thought about reflection and I'm not so sure..

22-Mar-2013 16:44, renoX пишет:
> On Friday, 22 March 2013 at 11:14:47 UTC, Dmitry Olshansky wrote:
>> I'd hate any solution that distances ordinary structs, library tuples
>> and fixed-sized arrays.
>
> Are struct/tuples similar to fixed-sized array?
> I thought that both are different because you can select which element
> you access at runtime in an array, but usually this is not possible with
> structs and tuples where this is selected at compile time and then I
> thought about reflection and I'm not so sure..

Fundamentaly there is no difference at all as long as data layout is the same.

The fact that you sort of can't easily index tuple of 3 ints as a fixed array of 3 ints is a clear indication of a tendency that I find disturbing.

Anyway D is a systems language so you can just blast your way past these limitations:

auto abc = Tuple!(int, int, int)(1, 4, 5);

int[3] data = *cast(int[3]*)&abc;

... //now you can

alternatively even to dynamic array:

int[] dynViewOf = (cast(int*)&abc)[0..3];

There is no escaping the fact that it's just a piece of data structured in a certain way.

-- 
Dmitry Olshansky

> The fact that you sort of can't easily index tuple of 3 ints as a fixed array of 3 ints is a clear indication of a tendency that I find disturbing.

But there is a reason for this: tuple/structs can contain heterogeneous type whereas array contains only homogeneous type..
So if you want to index a tuple/struct of say {int,int[128]} you have to build an array of pointers to these index, possible but clearly not free..
So I wouldn't agree that tuple/struct are 'trivially substitutable' to array..

On Friday, 22 March 2013 at 13:41:31 UTC, renoX wrote:
>> The fact that you sort of can't easily index tuple of 3 ints as a fixed array of 3 ints is a clear indication of a tendency that I find disturbing.
>
> But there is a reason for this: tuple/structs can contain heterogeneous type whereas array contains only homogeneous type..
> So if you want to index a tuple/struct of say {int,int[128]} you have to build an array of pointers to these index, possible but clearly not free..
> So I wouldn't agree that tuple/struct are 'trivially substitutable' to array..

No. A tuple is by definition an ordered, finite sequence of elements. There is no problem to index that.

tuple a = {
   5;
   true;
   0.1
}
is(typeof(a[0]) == int)
is(typeof(a[1]) == bool)

On Friday, 22 March 2013 at 14:23:53 UTC, Tobias Pankrath wrote:
>>
>> But there is a reason for this: tuple/structs can contain heterogeneous type whereas array contains only homogeneous type..
>> So if you want to index a tuple/struct of say {int,int[128]} you have to build an array of pointers to these index, possible but clearly not free..
>> So I wouldn't agree that tuple/struct are 'trivially substitutable' to array..
>
> No. A tuple is by definition an ordered, finite sequence of elements. There is no problem to index that.
>
> tuple a = {
>    5;
>    true;
>    0.1
> }
> is(typeof(a[0]) == int)
> is(typeof(a[1]) == bool)

>There is no problem to index that.

because the layout should be known at compile time.

22-Mar-2013 17:41, renoX пишет:
>> The fact that you sort of can't easily index tuple of 3 ints as a
>> fixed array of 3 ints is a clear indication of a tendency that I find
>> disturbing.
>
> But there is a reason for this: tuple/structs can contain heterogeneous
> type whereas array contains only homogeneous type..

Surely I know this don't you think ? ;)

> So if you want to index a tuple/struct of say {int,int[128]} you have to
> build an array of pointers to these index, possible but clearly not free..

This example is trivially done with single point provided you know the layout/padding. There are ways to peek at that in D too.

In general yes, heterogeneous is what makes structs and tuples standout.

> So I wouldn't agree that tuple/struct are 'trivially substitutable' to
> array..
>

In the case of exactly the same data layout they do. Plenty of cases are like this e. g.  2-d, 3-d points being structs. These could be treated as arrays easily.

Otherwise it is a good idea to not try to when it doesn't make sense.

-- 
Dmitry Olshansky

> Denis Shelomovskij:
>
>> D already have undocumented[1] front tuple expansion in foreach over range:
>> ---
>> import std.algorithm;
>> import std.stdio;
>>
>> void main() {
>>    enum s = "this is an example for huffman encoding"d;
>>    foreach (c, n; s.dup.sort().release().group())
>>        writefln("'%s'  %s", c, n);
>> }
>
>
> I know, but it doesn't work in the case of my code I have shown, with a SortedRange of 2-tuples:
>
> void main() {
>     auto s = "this is an example for huffman encoding"d;
>     foreach (c, n; s.dup.sort().release.group.encode)
>         writefln("'%s'  %s", c, n);
> }


So I have suggested to remove that syntax and replace it with a syntax that is more explicit, more flexible and more general:

http://d.puremagic.com/issues/show_bug.cgi?id=9817

Bye,
bearophile