• H. S. Teoh via Digitalmars-d (23/23) Nov 13 2014 Recently, some good progress has been made in cleaning up the messy web
• Rikki Cattermole (14/35) Nov 13 2014 std.range.checks
• David Nadlinger (7/8) Nov 14 2014 For this, std.range.constraints would also be perfectly fine. The
• Brad Anderson (6/14) Nov 14 2014 Perhaps they shouldn't be in the same module then.
• H. S. Teoh via Digitalmars-d (7/24) Nov 14 2014 OTOH, the current std.range also has a lot of other "adapters" like
• Dicebot (3/19) Nov 14 2014 As far as I understand idea is exactly to separate it (while
• Dicebot (3/19) Nov 14 2014 As far as I understand idea is exactly to separate it (while
• Dicebot (2/4) Nov 14 2014 (that was my original proposal when reviewing PR too)
• Nick Treleaven (4/7) Nov 19 2014 If it's not too late, can we change the name to std.range.traits? It
• H. S. Teoh via Digitalmars-d (8/17) Nov 19 2014 It's not too late until the next release.
• monarch_dodra (12/34) Nov 21 2014 I think "constraints" should be called "traits", because that's
• Dicebot (4/4) Dec 04 2014 I disagree that `traits` and `constraints` are the same.
• Dicebot (1/1) Nov 14 2014 std.range.primitives ?
• Dmitry Olshansky (4/5) Nov 14 2014 +1
• H. S. Teoh via Digitalmars-d (6/10) Nov 14 2014 [...]

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

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.

Rikki Cattermole <alphaglosined gmail.com> writes:

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

"David Nadlinger" <code klickverbot.at> writes:

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

"Brad Anderson" <eco gnuk.net> writes:

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

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Fri, Nov 14, 2014 at 10:22:16PM +0000, 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.

"Dicebot" <public dicebot.lv> writes:

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)

"Dicebot" <public dicebot.lv> writes:

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)

"Dicebot" <public dicebot.lv> writes:

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)

Nick Treleaven <ntrel-pub mybtinternet.com> writes:

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.

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Wed, Nov 19, 2014 at 06:06:26PM +0000, 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"??

"monarch_dodra" <monarchdodra gmail.com> writes:

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 +0000, 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.

"Dicebot" <public dicebot.lv> writes:

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.

"Dicebot" <public dicebot.lv> writes:

std.range.primitives ?

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

15-Nov-2014 00:17, Dicebot пишет:
 std.range.primitives ?

+1

-- 
Dmitry Olshansky

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

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!