Re: New std.range submodule
I disagree that `traits` and `constraints` are the same. Constraint is a specific case of a trait which returns boolean value and has semantical from of `isSomething`. Trait is pretty much any static reflection utility, whatever it does.
Re: New std.range submodule
On Wednesday, 19 November 2014 at 18:22:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Nov 19, 2014 at 06:06:26PM +, Nick Treleaven via Digitalmars-d wrote: On 14/11/2014 21:52, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming. It's not too late until the next release. I prefer std.range.primitives, since it's not just traits, but also includes things like range API for built-in arrays (.front, .empty, .popFront). T I think constraints should be called traits, because that's what it actually is, and the top level module is called traits (eg: isSomeString == isForwardRange). It makes little sense to me for both to have different names. The popFront/moveFront and friends I think belong in primitives. It sounds nice. Also, every package std.range.* should publicly include std.range.constraints too. That's what container does, in that every sub package also includes the the make in std.container.utility.
Re: New std.range submodule
On 14/11/2014 21:52, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming.
Re: New std.range submodule
On Wed, Nov 19, 2014 at 06:06:26PM +, Nick Treleaven via Digitalmars-d wrote: On 14/11/2014 21:52, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming. It's not too late until the next release. I prefer std.range.primitives, since it's not just traits, but also includes things like range API for built-in arrays (.front, .empty, .popFront). T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked submit??
Re: New std.range submodule
std.range.primitives ?
Re: New std.range submodule
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array-range adapters that are definitely not constraints, checks, or however else you might call them. David
Re: New std.range submodule
15-Nov-2014 00:17, Dicebot пишет: std.range.primitives ? +1 -- Dmitry Olshansky
Re: New std.range submodule
On Sat, Nov 15, 2014 at 12:56:33AM +0300, Dmitry Olshansky via Digitalmars-d wrote: 15-Nov-2014 00:17, Dicebot пишет: std.range.primitives ? +1 [...] Mmmm, I like that. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: New std.range submodule
On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array-range adapters that are definitely not constraints, checks, or however else you might call them. David Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters
Re: New std.range submodule
On Fri, Nov 14, 2014 at 10:22:16PM +, Brad Anderson via Digitalmars-d wrote: On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array-range adapters that are definitely not constraints, checks, or however else you might call them. David Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters OTOH, the current std.range also has a lot of other adapters like cycle, take, etc.. Which you probably don't want to be importing every time just because you need to use array range primitives. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Re: New std.range submodule
On Friday, 14 November 2014 at 22:22:17 UTC, Brad Anderson wrote: On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array-range adapters that are definitely not constraints, checks, or however else you might call them. David Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters As far as I understand idea is exactly to separate it (while release has not happened and it is not too late)
Re: New std.range submodule
On Friday, 14 November 2014 at 22:47:38 UTC, Dicebot wrote: As far as I understand idea is exactly to separate it (while release has not happened and it is not too late) (that was my original proposal when reviewing PR too)
Re: New std.range submodule
On Friday, 14 November 2014 at 22:22:17 UTC, Brad Anderson wrote: On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array-range adapters that are definitely not constraints, checks, or however else you might call them. David Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters As far as I understand idea is exactly to separate it (while release has not happened and it is not too late)
New std.range submodule
Recently, some good progress has been made in cleaning up the messy web of imports between Phobos modules, so that importing one module for a single function won't also pull in half of Phobos. Part of this work has been to separate the range API constraints (isInputRange, hasLength, isForwardRange, etc.) from std.range into a new submodule currently named std.range.constraints. However, we are considering renaming it to a better name, because currently it also contains a bunch of stuff that are *not* constraints per se -- such as the range primitives for built-in arrays. They were put there because they are often used together with the range API constraints, and any code that uses them would also need to import the constraints anyway. Any ideas for a better name for this submodule? We'd like to get this decided before the next release, after which it will be more troublesome to rename it. Possible alternatives include: - std.range.core - std.range.api - etc. Any other suggestions? T -- Without outlines, life would be pointless.
Re: New std.range submodule
On 14/11/2014 6:30 p.m., H. S. Teoh via Digitalmars-d wrote: Recently, some good progress has been made in cleaning up the messy web of imports between Phobos modules, so that importing one module for a single function won't also pull in half of Phobos. Part of this work has been to separate the range API constraints (isInputRange, hasLength, isForwardRange, etc.) from std.range into a new submodule currently named std.range.constraints. However, we are considering renaming it to a better name, because currently it also contains a bunch of stuff that are *not* constraints per se -- such as the range primitives for built-in arrays. They were put there because they are often used together with the range API constraints, and any code that uses them would also need to import the constraints anyway. Any ideas for a better name for this submodule? We'd like to get this decided before the next release, after which it will be more troublesome to rename it. Possible alternatives include: - std.range.core - std.range.api - etc. Any other suggestions? T std.range.checks I use this naming scheme for modules (with their purpose) for heavy ctfe code. Checks are: 1. Free functions 2. Expected to run at compile time only 3. Pure 4. Are templated Helpers are: 1. Free functions 2. Expected to run at runtime 3. Not pure 4. May or may not be templated
