On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:
> We should start a new thread in "General" to ask whether people care about the `ref`-ness of `Tuple` slices is really the deciding factor.

I made a poll: http://forum.dlang.org/post/inswmiscuqirkhfqlhtd@forum.dlang.org

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:
> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
>> I understand that. We just have a different perspective on the problem. Your priorities:
>>
>> - don't break what's not broken
>> - .slice! lends on opSlice and should return by ref
>>
>> My priorities:
>>
>> - type of .slice! should be as if constructing with same
>>   values from scratch
>> - keep code additions in Phobos to a minimum
>>
>> Why do I insist on the return type? Because surprisingly simple code breaks if it doesn't match. Not everything can be covered by runtime conversions in D.
>
> I think the key question is, do users care about being able to modify the original `Tuple` instance indirectly through `slice`?
>
> If yes, then the only workable solutions I can see are:
>
> 1) My current proposal (insert a hidden padding member at the beginning of the slice `Tuple`)
>
> 2) Don't return a `Tuple` at all - return a dedicated `TupleSlice` type that is implicitly convertible to `Tuple`. This approach would work with the example you came up with, but implementing `TupleSlice` well could be very complex, I think.
>
> If not, then I have no fundamental objection to Saurabh Das' approach, although I think the PR needs work.

The PR definitely needs work - it was proposed to outline the direction. I haven't worked at all on Phobos and I am not yet knowledgeable on writing library-quality code in D.

I'm hoping to contribute back to Phobos this year - so pointing out as many flaws will help learn faster :) In particular - the inout problem in the PR - I'm not sure yet on how to fix that.

Thanks,
Saurabh

>
> We should start a new thread in "General" to ask whether people care about the `ref`-ness of `Tuple` slices is really the deciding factor.

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
> What I like most about your proposal is that it doesn't break any existing code that wasn't broken before. That can't be emphasized enough.

Although I wish more than 3 people had voted in my poll, two of them did claim to need the `ref`-ness of `Tuple.slice`, so I don't think we can just ditch it. (I did not vote.)

If you guys want to add a return-by-value version, it should be treated as an enhancement, not a bug fix in my opinion.

Am Tue, 09 Feb 2016 00:38:10 +0000
schrieb tsbockman <thomas.bockman@gmail.com>:

> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
> > What I like most about your proposal is that it doesn't break any existing code that wasn't broken before. That can't be emphasized enough.
> 
> Although I wish more than 3 people had voted in my poll, two of them did claim to need the `ref`-ness of `Tuple.slice`, so I don't think we can just ditch it. (I did not vote.)
> 
> If you guys want to add a return-by-value version, it should be treated as an enhancement, not a bug fix in my opinion.

As mentioned I never used the feature myself and wont vote for one or the other. Three people with no source code to exemplify current use of .slice! is indeed not much to base decisions on and both fixes yield unexpected results in different contexts that warrant bug reports.

-- 
Marco

On Tuesday, 9 February 2016 at 06:22:55 UTC, Marco Leise wrote:
> As mentioned I never used the feature myself and wont vote for one or the other. Three people with no source code to exemplify current use of .slice! is indeed not much to base decisions on...

The mere fact that all I had to do to find people who use and care about the `ref`-ness of `Tuple.slice` was ask, and then wait a few hours, strongly suggests that there are other such people among the D user base.

When faced with a judgment call like this, we really ought to err on the side of maintaining backwards compatibility - especially since this does not preclude adding a separate by-value version of `Tuple.slice`, as well. It was going to need a new name anyway.

On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote:
> When faced with a judgment call like this, we really ought to err on the side of maintaining backwards compatibility - especially since this does not preclude adding a separate by-value version of `Tuple.slice`, as well. It was going to need a new name anyway.

I suggest lobbying for proper builtin tuple support. IMO one shouldn't be able to take the reference of a tuple, to ensure that it can be kept in registers. Modern desktop CPUs have maybe 512 bytes of register space. In most cases a tuple will be within 8 bytes * 16 or something like that.

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote:
> IMO one shouldn't be able to take the reference of a tuple, to ensure that it can be kept in registers.

No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this.

On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
> No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this.

If you don't restrict the language people will write code that the optimizer will struggle with.  LLVM can only handle what goes on within a compilation unit, and not if there are stores, because those are visible in other threads.

Tuples should be considered immutable constants (think functional programming), not in-memory storage.

Tuple's can serve as a good approximation to SIMD registers.

On Tuesday, 9 February 2016 at 11:38:14 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
>> No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this.
>
> If you don't restrict the language people will write code that the optimizer will struggle with.

So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and arrays?

> LLVM can only handle what goes on within a compilation unit, and not if there are stores, because those are visible in other threads.
>
> Tuples should be considered immutable constants (think functional programming), not in-memory storage.
>

Again, why?

> Tuple's can serve as a good approximation to SIMD registers.

What relation does that have to the above?

On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
> So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and arrays?

Some key common qualities for a tuple:

1. They are primarily used for multiple return values from functions.

2. Tuples use structural typing, not nominal typing.

3. They are identity-less. If you can take reference and compare, they no longer are identity-less.


>> Tuples should be considered immutable constants (think functional programming), not in-memory storage.
>
> Again, why?

Because that is how a tuple is commonly defined, for performance and semantic reasons.


>> Tuple's can serve as a good approximation to SIMD registers.
>
> What relation does that have to the above?

You don't want to spill out SIMD registers to the stack if you can avoid it. You want to do the changes within the CPU pipeline, i.e. using copies (and register renaming).