Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Wednesday, October 17, 2012 00:27:08 Era Scarecrow wrote:
> On Tuesday, 16 October 2012 at 17:06:06 UTC, Jonathan M Davis
> 
> wrote:
> > There's also no way to validate that front always returns the
> > same value, or that popFront actually pops a value, or that it
> > pops only one value, etc. Pretty much _all_ that we can verify
> > with template constraints is function signatures. So, we can
> > _never_ fully restrict range types to exactly what would be
> > considered correct.
> 
> An option that may be decided on, is if an enum is used to
> specify certain behavior decisions made by the programmer, then
> only a few new templates to check for those and return true when
> those are specifically true. Perhaps an example to use?
> 
> 
> enum RangeTypes { normal, mutating, popDisgarded, ... }
> 
> 
> template isRangeMutating(T)
> if (hasMember!(T, "rangeType")) {
> enum isRangeMutating = T.rangeType == RangeType.mutating;
> }
> 
> 
> //function that cannot accept input range that mutates any
> members due to
> //popFront/popBack
> void something(I)(I input)
> if (isInputRange!(I) && (!isRangeMutating!(I)))
> { /*...*/ }

We arguably have to many traits to check for ranges already. This is just 
overcomplicating things IMHO. Ranges should not be this complicated. They're 
pushing it in that regard as it is.

- Jonathan M Davis