"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