On Thursday, 27 March 2014 at 02:08:04 UTC, Jakob Ovrum wrote:
On Tuesday, 25 March 2014 at 17:22:45 UTC, monarch_dodra wrote:
I think this is wrong. popping an empty range is an *Error*,
and should be validated by the programmer. Because of this, it
is currently not possible to use "reduce(range)" in nothrow
context.
Popping an empty range is indeed an error, but that's not the
issue here. The issue is whether or not it should check for
empty, i.e. whether an empty input is valid. Other looping
eager algorithms - like `sum` and indeed `copy` - do accept
empty inputs.
I understand the issue of nothrow of course; I think it's
likely that in most real-world use cases, reduce/fold will be
used on guaranteed non-empty inputs, *but not always*, and I'd
hate for release-build-only dangerous bugs to sneak into
programs because of it.
Maybe we should have some kind of NonEmpty higher-order range
type that algorithms can overload on, ala how std.container
deals with Take? It could be initialized with
`assumeNonEmpty(r)` and/or `checkNonEmpty(r)`.
I'm not sure I understand this right, but are you or Monarch
proposing to disallow calling it with an empty range? I believe
this would be really bad, especially for generic code.
Folding/reducing an empty range should just return the seed
value, not be an error.
