On Saturday, 6 February 2016 at 08:01:20 UTC, tsbockman wrote:
On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:
[...]
I should also point out that, since there is no way to actually
find out whether anyone is using the `ref`-ness of the return
type in the wild, the approach that you and Saurabh Das are
taking really ought to include changing the symbol name and
deprecating the old one.
Otherwise you could introduce subtle bugs into previously valid
code; not every significant effect of removing `ref` will cause
an error message at compile time *or* run time - some will just
silently change the behaviour of the program, which is awful.
I think we should add a static assert to slice to ensure that the
current implementation is not used in a case where the alignment
doesn't match. This is better than failing without any warning.
We could add new (differently named) functions for slicing
non-aligned tuples.
I agree that my approach of removing the ref may break existing
code, so if introduced, it should be named differently.
I am not comfortable with tuple(42, true, "abc").slice(1, 3)
being different in type from tuple(true, " abc").
