On Tuesday, 20 December 2016 at 17:28:49 UTC, Stefan Koch wrote:
> 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)

Thanks!
Sorry for the noise!

On Tuesday, 20 December 2016 at 15:47:38 UTC, Nordlöw wrote:
> 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?

Back in May a change was introduced to issue a deprecation message for uses of the comma operator outside of a for statement. Not sure which dmd version it got introduced into but it's surely in there by now.

https://github.com/dlang/dmd/pull/5737

On 20.12.2016 14:47, Ilya Yaroshenko wrote:
> One good thing for safety and CTFE is allow multiple return value. In
> combination with `auto ref` it is _very_ powerful:
>
> ----
> auto ref front()
> {
>   // Returns 2 values, each value is returned by reference if possible
>   return (a.front, b.front);
> }
> ----
> ...


There is already syntax for something similar to this (for the auto-expanding version).

auto ref seq(T...)(return auto ref T args){
    return args;
}

auto ref front(){
    return seq(a.front, b.front);
}

However, DMD will reject this at the moment.


> Mir libs will use pointers for now. This is one of reasons why `zip` is
> slow.
> The new feature also significantly extends std.range and std.algorithm
> functionality.
>
> This thread was forked from
> http://forum.dlang.org/post/acdwfbirvoxzrsfyltqd@forum.dlang.org
>
> I am not good in DIPs and hope someone is interested in this feature too

This will likely be added as soon as the comma operator has finished its deprecation cycle. (I might give this a shot after finally polishing the static foreach DIP.)

On Tuesday, 20 December 2016 at 17:28:49 UTC, Stefan Koch wrote:
> 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)

`Tuple` + pointers do not help. Multiple auto ref values are required anyway. The reason is that tuple.expand analog can not pass something by reference from original ranges (it has pointers and values).

Multiple auto ref values are required to have syntax like this:

zip(a, b).each!swap;

I know that we have swapRanges, but this is not solution for Mir because Mir should have small API without hundreds of trivial functions like in Armadillo.

Thanks,
Ilya

On Tuesday, 20 December 2016 at 18:51:05 UTC, Brad Anderson wrote:
>> Could the comma expression be contextually removed? Specifically in return expressions as discussed initially in this post?
>
> Back in May a change was introduced to issue a deprecation message for uses of the comma operator outside of a for statement.

Not quite, the comma expression can be used anywhere so long as the result is not used.

http://dlang.org/changelog/2.072.0.html#deprecated_commaexp