Isn't `each` too much of a good thing?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 17 20:07:35 UTC 2020


On Thu, Sep 17, 2020 at 01:41:00PM -0600, Jonathan M Davis via Digitalmars-d wrote:
[...]
> Regardless, IMHO, we should be avoiding support for static arrays and
> opApply in range-based code. At most, maybe there should be a way to
> convert a type with opApply to a range, but static arrays are already
> solved just by slicing them. In general, by requiring that someone
> explicitly do a conversion or wrap something in another type in order
> to make it a range, we can really simplify code.

Yes, yes, and yes!  Separate out the concerns by letting another
function take care of adapting {static array, opApply iterable, what
have you} to the range API, then delete the non-range code that the
implementation currently has.  Result: cleaner code, more modular, and
each piece is more reusable (the adaptor can be used for other things
besides .each).


[...]
> I honestly wish that static arrays didn't even implicitly convert to
> dynamic arrays.

That bug has been filed for years, I wish somebody would take it up and
push it in. :-/  That has been a bad idea for years and yet it still
persists.

	https://issues.dlang.org/show_bug.cgi?id=15932


> If we're really going to do another version of Phobos and rework
> ranges, then I think that as part of that, we should make various
> rules about how Phobos will handle ranges (and how most code should
> handle ranges) clear.  Even when there's agreement on some of that
> stuff right now among most of the key developers, it's not necessarily
> well-documented. We should probably have explicitly documented rules
> and guidelines about stuff like not supporting static ranges in
> range-based code. That would then at least allow us to avoid some of
> the problems like shown here with each - as well as better document
> how ranges work and are supposed to be used in general.
[...]

Yes, and we need water-tight wording in the documentation to leave no
ambiguities in things like how things get copied around (or not), what
happens after passing a to a function and the function returns,
transient .front, ref, const, etc..  All seemingly trivial things, but
left unadddressed, they can really become thorns in our sides.


T

-- 
An elephant: A mouse built to government specifications. -- Robert Heinlein


More information about the Digitalmars-d mailing list