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.

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

std.range.primitives ?

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

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

+1

-- 
Dmitry Olshansky

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!

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

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.

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)

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)