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
