Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad wrote: 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

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote: I suggest lobbying for proper builtin tuple support. Built-in tuple support would be great (although to my mind, mostly because the current syntax is clunky). But that is a long-term goal, and `Tuple.slice` is corrupting

Re: Is this a bug in std.typecons.Tuple.slice?

On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote: [...] `Tuple.slice` is corrupting data *right now*. Some sort of short-term fix should be merged in the next release of D. +1

Re: Is this a bug in std.typecons.Tuple.slice?

Am Tue, 09 Feb 2016 00:38:10 + schrieb tsbockman : > 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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 11:02:37 + schrieb tsbockman : > On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: > > 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

Re: Is this a bug in std.typecons.Tuple.slice?

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/inswmiscuqirkhfql...@forum.dlang.org

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: 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. It still took me a while to come up with something obvious:

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 07:57:08 + schrieb tsbockman : > On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: > > I don't want to sound dismissive, but when that thought came > > to my mind I considered it unacceptable that the type of > > Tuple!(int, bool,

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: I don't want to sound dismissive, but when that thought came to my mind I considered it unacceptable that the type of Tuple!(int, bool, string).slice(1, 3) would be something different than Tuple!(bool, string). In your case

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: 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. If we pursue the deprecation

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 04:28:17 + schrieb tsbockman : > On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: > >> > 1. Removing 'ref' from the return type > > > > Must happen. 'ref' only worked because of the reinterpreting > > cast which doesn't work in

Re: Is this a bug in std.typecons.Tuple.slice?

Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : > On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: > [...] > > Apologies for spamming. This is an improved implementation: > > @property > Tuple!(sliceSpecs!(from, to)) slice(size_t

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: > 1. Removing 'ref' from the return type Must happen. 'ref' only worked because of the reinterpreting cast which doesn't work in general. This will change the semantics. Now the caller of 'slice' will deal with a whole new copy

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : [...] That is enlightening. I have updated the PR at https://github.com/D-Programming-Language/phobos/pull/3975 to incorporate these changes.

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Thank you. I understood why this is happening from your explanation in the bug report.

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote: This code: [...] Update: Simplified, this also doesn't work: void main() { import std.typecons; auto tp = tuple(10, false, "hello"); auto u0 = tp.slice!(0, tp.length); auto u1 = tp.slice!(1, tp.length); auto

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Is this a possible fixed implementation? : @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @trusted const if (from <= to && to <=

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] Apologies for spamming. This is an improved implementation: @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @safe const if (from <= to && to <= Types.length) {

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] PS: Additionally, '@trusted' can now be substituted with '@safe'.

Re: Is this a bug in std.typecons.Tuple.slice?

https://issues.dlang.org/show_bug.cgi?id=15645

Re: Is this a bug in std.typecons.Tuple.slice?

Am Thu, 04 Feb 2016 15:17:54 + schrieb Saurabh Das : > On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote: > > This code: > > [...] > > Update: Simplified, this also doesn't work: > > void main() > { > import std.typecons; > auto tp = tuple(10,