www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Second CT-Parameter of isRange Predicates

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Is there a reason why

     isOutputRange(R,E)

takes a second argument `E` but not other range predicates

     isInputRange(R)
     isForwardRange(R)
     ...

?

If so, I still think it would very be nice to have a second 
argument `E` for all the other `isXRange` traits to simplify, for 
instance,

     if (isInputRange!R && is(int == ElementType!R))

to simpler

     if (isInputRange!(R, int))

or even

     if (isInputRange!R && is(isSomeChar!(ElementType!R)))

to simpler

     if (isInputRange!(R, isSomeChar))

?

What do think?

I'm planning to add a PR for this and simplify Phobos in all 
places where this pattern is used.
Nov 02 2015
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:
 Is there a reason why

     isOutputRange(R,E)

 takes a second argument `E` but not other range predicates

     isInputRange(R)
     isForwardRange(R)
     ...

 ?

 If so, I still think it would very be nice to have a second 
 argument `E` for all the other `isXRange` traits to simplify, 
 for instance,

     if (isInputRange!R && is(int == ElementType!R))

 to simpler

     if (isInputRange!(R, int))

 or even

     if (isInputRange!R && is(isSomeChar!(ElementType!R)))

 to simpler

     if (isInputRange!(R, isSomeChar))

 ?

 What do think?

 I'm planning to add a PR for this and simplify Phobos in all 
 places where this pattern is used.
https://github.com/D-Programming-Language/phobos/pull/3786 Atila
Nov 02 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Nov 02 2015
next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Why not extend existing traits with a second `E`-parameter instead of adding a new one?
Nov 02 2015
next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
 wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Why not extend existing traits with a second `E`-parameter instead of adding a new one?
I think it's very well worth it in terms of expressability.
Nov 02 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/02/2015 09:43 AM, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Why not extend existing traits with a second `E`-parameter instead of adding a new one?
I think it's very well worth it in terms of expressability.
I'd say it's a minor convenience. Anyhow, integrating tests this way depends on how we go about reporting "no match" errors. In the constraint isForwardRange!R && is(ElementType!R == int) the compiler could report exactly: "isForwardRange!Widget failed" or "is(ElementType!Widget == int) failed". If tests are combined, the compiler will only be able to say "isForwardRange!(Widget, int) failed". Andrei
Nov 02 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 2 November 2015 at 15:00:23 UTC, Andrei Alexandrescu 
wrote:
 On 11/02/2015 09:43 AM, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:33:44 UTC, Andrei 
 Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Why not extend existing traits with a second `E`-parameter instead of adding a new one?
I think it's very well worth it in terms of expressability.
I'd say it's a minor convenience.
I'm actually a bit surprised at the suggestion, since I would have expected most code to either not care what the ElementType was or to have to test something about it other than simply testing for an exact type. And given how frequently Unqual needs to get involved with tests on ElementType, simply testing the exact type would likely be problematic for many of the common cases that would initially seem to benefit from having isInputRange!(R, E) as a shortcut. So, it might be nice to have in some cases, but in general, I don't think that it's expressive enough, and I don't like how it's not orthogonal to the existing traits, since it's really just combining two of them. - Jonathan M Davis
Nov 02 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 3 November 2015 at 03:26:47 UTC, Jonathan M Davis 
wrote:
 On Monday, 2 November 2015 at 15:00:23 UTC, Andrei Alexandrescu 
 wrote:
 On 11/02/2015 09:43 AM, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 On Monday, 2 November 2015 at 14:33:44 UTC, Andrei 
 Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
Why not extend existing traits with a second `E`-parameter instead of adding a new one?
I think it's very well worth it in terms of expressability.
I'd say it's a minor convenience.
I'm actually a bit surprised at the suggestion, since I would have expected most code to either not care what the ElementType was or to have to test something about it other than simply testing for an exact type.
Am I the only one who ever writes `int[]` or `Struct[]` in a function signature? Atila
Nov 03 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
 Am I the only one who ever writes `int[]` or `Struct[]` in a 
 function signature?
Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic. - Jonathan M Davis
Nov 03 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 3 November 2015 at 10:08:04 UTC, Jonathan M Davis 
wrote:
 On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
 Am I the only one who ever writes `int[]` or `Struct[]` in a 
 function signature?
Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic. - Jonathan M Davis
I'd _like_ to write functions that take ranges instead; that's why I want to make it easier to declare "this parameter is an input range of T". Atila
Nov 04 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 4 November 2015 at 10:37:54 UTC, Atila Neves wrote:
 On Tuesday, 3 November 2015 at 10:08:04 UTC, Jonathan M Davis 
 wrote:
 On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
 Am I the only one who ever writes `int[]` or `Struct[]` in a 
 function signature?
Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic. - Jonathan M Davis
I'd _like_ to write functions that take ranges instead; that's why I want to make it easier to declare "this parameter is an input range of T".
I confess that I don't find is(ElementType!E == Foo) to be particularly onerous. If that's what I need, then I do it and move on. It takes less time to write than this post, and it's not that uncommon that far more complicated conditions are required for template constraints anyway. So, while I can understand why you'd want it to be simpler, it really doesn't seem like a big deal to me. And for that matter, if you really do want it to be simpler, there's nothing stopping you from creating your own traits to test with rather than just those in Phobos. It just means that it's not something that's going to be commonly used. IMHO, if anything is annoying about writing template constraints, it's dealing with several overloads, since that frequently requires that you essentially put the negation of each overload in the other overloads. - Jonathan M Davis
Nov 04 2015
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 Why not extend existing traits with a second `E`-parameter 
 instead of adding a new one?
What will E be when you only care whether R is an InputRange and not about its ElementType?
Nov 02 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 3 November 2015 at 01:36:31 UTC, Sebastiaan Koppe 
wrote:
 On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
 Why not extend existing traits with a second `E`-parameter 
 instead of adding a new one?
What will E be when you only care whether R is an InputRange and not about its ElementType?
I think that the idea was that we'd keep isInputRange as-is (in which case, if you don't care about the element type, then you use that), and then we'd add an overload of isInputRange which took two arguments where the second argument is the ElementType. - Jonathan M Davis
Nov 02 2015
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
wrote:
 https://github.com/D-Programming-Language/phobos/pull/3786
Sent an ICBM its way. -- Andrei
I agree with the ICBM that it definitely doesn't scale. But... there should be an easier way to replace arrays of Widget with a range. If not, most people (including me on lazy days) will just write `Widget[]` and be done with it. I don't know what the best solution is. I'm saying this as someone who's written plenty of D code that takes arrays as arguments not because it's right, but because it was a lot easier and I didn't want it getting in the way of whatever it is I was trying to accomplish.. 90% of my usage of `std.array.array` is depressingly enough at the end of an algorithm UFCS chain because either I'm passing this to a function expecting `T[]` or to a struct that stores `T[]`. It's not pretty, performant, or right, but it's easy and I'm lazy. And that's for writing code. With regards to reading, it's been pointed out multiple times that beginners will struggle with template contraints on function signatures. It'll be the case much more often if every function and struct wanting a range of Ts is suddenly `if(isInputRange!R && is(ElementType!R == T))`. Atila
Nov 02 2015
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 2 November 2015 at 15:33:54 UTC, Atila Neves wrote:
 And that's for writing code. With regards to reading, it's been 
 pointed out multiple times that beginners will struggle with 
 template contraints on function signatures. It'll be the case 
 much more often if every function and struct wanting a range of 
 Ts is suddenly `if(isInputRange!R && is(ElementType!R == T))`.

 Atila
I totally agree with you Atila. The whole point of this addition is not to find an alternative way of restricting templates for all you already skilled D developers that comment on this thread but instead: *to make D easier to assimilate for beginners* so we can achieve, according Andrei, our most important goal - grow by two orders of magnitude...that's why I believe these things really matter.
Nov 03 2015
prev sibling parent Alex Parrill <initrd.gz gmail.com> writes:
On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:
 Is there a reason why

     isOutputRange(R,E)

 takes a second argument `E` but not other range predicates

     isInputRange(R)
     isForwardRange(R)
     ...

 ?

 If so, I still think it would very be nice to have a second 
 argument `E` for all the other `isXRange` traits to simplify, 
 for instance,

     if (isInputRange!R && is(int == ElementType!R))

 to simpler

     if (isInputRange!(R, int))

 or even

     if (isInputRange!R && is(isSomeChar!(ElementType!R)))

 to simpler

     if (isInputRange!(R, isSomeChar))

 ?

 What do think?

 I'm planning to add a PR for this and simplify Phobos in all 
 places where this pattern is used.
I think it's because output ranges can accept more than one type of value. That said, the `isInputRange!(R,E)` shortcut for `isInputRange!R && is(int == ElementType!R)` would be nice.
Nov 02 2015