Policy for exposing range structs

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Fri Mar 25 07:07:41 PDT 2016


On 3/25/16 7:37 AM, Seb wrote:
> If I understand it correctly, the current policy in Phobos is that range
> methods should use static nested structs to avoid the name clutter and
> document the capabilities of the returned ranges in the documentation.
> However there are a lot of old functions that still use public structs,
> which leads to the rather confusing documentation output in std.range:
>
> Chunks · chunks · Cycle · cycle ... evenChunks · EvenChunks ·
> FrontTransversal · frontTransversal · ... · indexed · Indexed · .... ·
> lockstep · Lockstep · .. · Recurrence · recurrence · RefRange · refRange
> · repeat · Repeat · ... · sequence · Sequence · SortedRange · ... · Take
> · take · ... Transversal · transversal · TransverseOptions · zip · Zip
>
> (off-topic: it's quite interesting to see that sometimes the structs are
> before the method and sometimes after it)
>
> Two arguments to keep exposing the structs are that (1) an API user can
> explicitly specify the return type (in contrast to auto) and (2) one can
> see the capabilities of the struct in the documentation.
>
> There are many cases where methods in these structs are optional and
> depend on the capabilities of the input range (e.g. backward, length,
> random access, ...). I could imagine that
>
> 1) We rework ddoc, s.t. it doesn't list these structs in the overview
> and adds the struct methods to the function (could get ugly)
> 2) We deprecate those exposed structs and make them private/nested (does
> anyone know whether it's common to depend on those structs?)
>
> What are your thoughts on this matter?

We should actually be moving *away from* voldemort types:

https://forum.dlang.org/post/n96k3g$ka5$1@digitalmars.com

-Steve


More information about the Digitalmars-d mailing list