"fold": a replacement for "reduce"
Marc Schütz" <schuetzm at gmx.net>
Marc Schütz" <schuetzm at gmx.net>
Thu Mar 27 03:42:55 PDT 2014
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.
More information about the Digitalmars-d
mailing list