On 10.03.22 13:57, Adam D Ruppe wrote:
> On Thursday, 10 March 2022 at 12:49:57 UTC, Paul Backus wrote:
>> handling correctly.
> 
> objection, prejudiced language
> 

Pardon? It's pretty clear that it should not behave this way. The point of opApply is to overload on foreach syntax, where you can transparently exchange the type of aggregate. This is a headache for generic code that can loop either over an array or a struct with an opApply. There is zero justification for the meaning of the foreach loop body to change based on how the aggregate is expressed.

I guess __traits(parent, {}) and similar are also affected.

On Thursday, 10 March 2022 at 22:13:30 UTC, Timon Gehr wrote:
> *snip*

I don't really feel strongly about it. As it is, this will deliver value to me. What it does inside a foreach loop is immaterial to my use cases (and I suspect to just about any that can't be easier done with preexisting features).

On Thu, Mar 10, 2022 at 05:37:03PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> On the other hand, opApply is pretty out of favor now, so maybe it's not going to be as bad of an effect.
[...]

Parallel foreach still depends on opApply, though.  Is it really "out of favor"?


T

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)

On 10.03.22 23:37, Steven Schveighoffer wrote:
> 
> On the other hand, opApply is pretty out of favor now, so maybe it's not going to be as bad of an effect.

Maybe not, but it's death by a thousand little cuts with those things. I really dislike the stance of "let's document the wart, then it won't technically be a bug". This has been pretty rampant. It's so much better to have a known bug than to enshrine a known bad design in the spec...

> This really is one of those difficult to explain pieces to new users, and really difficult to get correct within generic code.

Yah. :( I can work around those issues, but they are rather embarrassing to explain to new developers on a project who are not even PL geeks and already a bit confused as to why D has been used in the first place. ("Why are you using D again if it can't get basic things like this right?") I do use opApply pretty extensively to implement tree traversals.

On 10.03.22 23:47, Adam Ruppe wrote:
> On Thursday, 10 March 2022 at 22:13:30 UTC, Timon Gehr wrote:
>> *snip*
> 
> I don't really feel strongly about it. As it is, this will deliver value to me. What it does inside a foreach loop is immaterial to my use cases (and I suspect to just about any that can't be easier done with preexisting features).

Fair enough. I think what should have been done is:

- Pull the buggy feature, comment out the test.
- Put an issue in bugzilla to be picked up by someone who actually needs this to work in foreach loops.

On 10.03.22 23:51, H. S. Teoh wrote:
> On Thu, Mar 10, 2022 at 05:37:03PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> On the other hand, opApply is pretty out of favor now, so maybe it's
>> not going to be as bad of an effect.
> [...]
> 
> Parallel foreach still depends on opApply, though.  Is it really "out of
> favor"?

Not with me. I think it's pretty useful. (It's a limited form of call/cc.)

Interestingly, parallel foreach barely uses the nicest parts of opApply:
"std.parallelism.ParallelForeachError@(0): Cannot break from a parallel foreach loop using break, return, labeled break/continue or goto statements."

On 11.03.22 00:58, MoonlightSentinel wrote:
> On Wednesday, 9 March 2022 at 10:04:57 UTC, Quirin Schroll wrote:
>> Please reconsider this design decision before it sticks.
> 
> Proposed fix: https://github.com/dlang/dmd/pull/13798

Thanks! That's probably going to be a lot more helpful than prolonged bickering on the forums. ;)

Note that there are some other __traits that have the same problem, notably __traits(parent, ...).