Is phobos too fluffy?

[H. S. Teoh]

On Thu, Sep 17, 2020 at 02:15:32PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/17/20 1:49 PM, jmh530 wrote:
[...]
> > When I looked at some of those examples above, I agree that some are
> > extraneous (which should get flagged by the autotester)...but I
> > almost always put an empty line after imports.
> 
> I was all in favor of that, until I had to refactor a dozen two-liners
> consisting of... let me paste some code:
> 
> auto put(ref GGPlotD gg, GeomBar def) {
>     import ggplot.backend.ggplot.geom_bar : geomBar;
> 
>     return gg.put(geomBar(def));
> }

Yeah, when it's just 2 lines like these, a blank line is just an eyesore
that serves no purpose.  I say we kill 'em.


> And so it goes for pages.
> 
> There is something to be said about a guideline versus a mindless
> dogma.  Things like enum strings, each, and autodecoding are more of
> the latter.

I'm on the fence about `each`.  I totally agree that the implementation
is a bit overblown -- do we *really* need to support static arrays,
opApply iterables, iteration indices, and all of that jazz?  Whenever we
end up with a combinatorial explosion of (sig constraint helper
templates, or any kind of code construct, really), it tells me that we
have failed to separate different concerns properly. Instead of writing
O(2^N) cases explicitly, at the most it ought to be O(N) cases, or,
better yet, O(1) (i.e., push tangential concerns out of the
implementation to the caller (or someone else)).

OTOH, I see why it might sometimes be a handy thing to have: if you have
a long UFCS chain, it can be an annoyance to have to wrap the entire
block with a `foreach (x; a.b.c.d.e.f.g./*...*/.z)` instead of being
able to just tack on `.each!(...)` at the end.  However, I'd say in this
case .each really should only support ranges, since UFCS chains are the
primary use case, and leave the other stuff like static arrays (not even
a range by current definitions), opApply-iterables, and AA's alone.

Of course, once you take all of that other fluff out, the raison d'etre
of .each becomes a little shaky. :-P  It's probably pushing it, but I'm
tempted to suggest that perhaps this is one of those opportunities
Andrei was talking about to improve the language: what if the language
equates:

	iterable.foreach(i => { ... });

with

	foreach (i; iterable) { ... }

?  I.e., the former lowers to the latter.  This seems to be a natural
(logical?) next step in the spirit of UFCS, except applied to built-in
loop constructs.

Then there would be no need of .each, and UFCS functional-style code
would be nicely unified with the good ole traditional loops.  And it
doesn't even need further compiler complications, being merely a simple
syntactic rewrite.

(Or perhaps this is illogical and just wayyyy out there... let the
rotten fruit fly. :-D)


T

-- 
Lottery: tax on the stupid. -- Slashdotter