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