On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote:
> DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D.

I wonder if it might be possible to add the tuple syntax incrementally into DMD? It's always easier to approve something less complex.

Could the comma expression be contextually removed? Specifically in return expressions as discussed initially in this post?

On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote:
> This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe

Do pointers worsen performance aswell? Even when using LDC?

On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote:
> On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote:
>> This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe
>
> Do pointers worsen performance aswell? Even when using LDC?

Tuples of pointers are faster then tuples of values. Hypothetical tuples of references have the same performance as tuples of references.

On Tuesday, 20 December 2016 at 16:06:49 UTC, Ilya Yaroshenko wrote:
> On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote:
>> On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote:
>>> This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe
>>
>> Do pointers worsen performance aswell? Even when using LDC?
>
> Tuples of pointers are faster then tuples of values. Hypothetical tuples of references have the same performance as tuples of references.

EDIT: as tuples of pointers.

On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote:
> No, tuples stores either value or pointer. If it stores pointer then it is not
> safe and it is not CTFE.

You can make it safe by using an array rather than a pointer.

On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote:
> This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe

The way to make this useful, if I'm understanding correctly, would not be a more concise way to express `return tuple(a, b);` where `tuple` is the function defined in typecons, but to make expressions like `return tuple(a, b).expand;` become valid and using a syntax like `return (a, b);` to represent them. (For which I would suggest also making the parentheses optional, but that's minutiae.)

The syntax for assigning the returned values would likely not look like `auto x = {return (a, b);}(); assert(x[0] == a);`. This because `x` would not be a tuple in the sense of std.typecons.Tuple, but a tuple in the sense of what you get when you `expand` such a type. The assignment syntax should be more like `auto x, y = {return (a, b);}(); assert(x == a);`. Where the intent is to store the two values in the same variable, I expect a struct like Tuple should continue to be used.

And because in these examples `a` and `b` would not be members of a tuple struct, it would become possible to return some or all of them by reference, as can currently be done for a single returned value.

On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote:
> On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote:
>> No, tuples stores either value or pointer. If it stores pointer then it is not
>> safe and it is not CTFE.
>
> You can make it safe by using an array rather than a pointer.

Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast?

On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote:
> On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote:
>> On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote:
>>> No, tuples stores either value or pointer. If it stores pointer then it is not
>>> safe and it is not CTFE.
>>
>> You can make it safe by using an array rather than a pointer.
>
> Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast?

What are you even talking about ?
Making a Tuple is fine.
Pointers can also be perfectly safe and CTFEable if you do not try to mess with them.
For a Range you have to pass some form of context regardless so there will always be a quite small price to be payed.

--
Performance is not something you just get.
Work is required if you want good performance and no library or language is going to change that.

On Tuesday, 20 December 2016 at 17:05:03 UTC, Stefan Koch wrote:
> On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote:
>> On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote:
>>> On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote:
>>>> No, tuples stores either value or pointer. If it stores pointer then it is not
>>>> safe and it is not CTFE.
>>>
>>> You can make it safe by using an array rather than a pointer.
>>
>> Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast?
>
> What are you even talking about ?
> Making a Tuple is fine.
> Pointers can also be perfectly safe and CTFEable if you do not

Are they already CTFEable? I have not seen an anounce, sorry

On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko wrote:
>
> Are they already CTFEable? I have not seen an anounce, sorry

They have been for years now.
Of course only pointers from a CTFE context are valid at ctfe.

The new engine will support them as well, (as it will eventually support everything with the exception of 80bit reals)