On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:

I don't need those? So hence I don't care…

This feature you are proposing with this DIP is a very important one in my view, and I would use it almost everywhere.

On Sunday, 6 February 2022 at 15:46:47 UTC, Ola Fosheim Grøstad wrote:

My point is that "I'm confused because I haven't read the documentation" is a very different complaint from "I'm confused because this feature is inherently confusing."

@mustUse will be documented in both the language spec (PR) and the DDoc for core.attribute (PR). If you're still confused after you've read the documentation, feel free to come back and complain to me then.

On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:

And while I am at it, let me commit heresy by proclaiming that this feature is so important that I think it should be the default and that programmers should instead specify that the result is "discardable".

That would of course be a terrible-terrible-terrible-breaking-change, and would never fly in the current political climate.

But in general: D would become more interesting as a language if we could muster the guts to be different.

On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote:

What I stated has nothing to do with documentation. I think the semantics are too important to be a "linter-feature". I also think C++ made a "mistake" by using an attribute for it.

On Sunday, 6 February 2022 at 16:01:15 UTC, Ola Fosheim Grøstad wrote:

What you stated was, and I quote:

My reply was directed towards that specific statement, and only that statement.

I did not reply (and do not intend to reply) to any of the numerous other statements you have made in your other replies to this thread, since they are statements about the design of the D language and the DIP process in general, and are not directly relevant to DIP 1038.

On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote:

Well, but it is relevant to the outcome.

In C++ I find that the more are strive to write semantically beautiful code, the less visually beautiful it becomes.

My modern C++ code is littered with [[nodiscard]] and other attributes.

If a language that is equally capable allows me to write code that is both semantically beautiful and visually beautiful then that would offset some of the disadvantages with using a small language. I think many C++ programmers feel that way.

Big opportunity that is up for grabs there.

On Sunday, 6 February 2022 at 17:07:46 UTC, Ola Fosheim Grøstad wrote:

Let me rephrase: I do not understand why you feel the need to direct these messages at me, personally. I am not a member of the D Language Foundation, and have no particular influence over the DIP process or the design of the D language.

If you have ideas or concerns you wish to present to D's leadership, my advice is to either (a) write a DIP, or (b) get in touch with Mike Parker about attending one of the D Language Foundation's monthly meetings (see the bottom of his latest meeting summary post for details).

On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote:

I am sorry if you felt I was addressing you personally. That was not intended, maybe bad phrasing on my part. (I tend to send email when addressing people personally! :-)

I am more trying to convey what I see has gone wrong in the "modern C++" design department to "the community" in some hope that D can do better. But right now it seems like "C++ did this" is treated like a validation, rather than a warning. "@mustUse" will literally be on every single function that I write that returns something… because it is almost always a bug to ignore a return value! In summary: This feature deserves a higher priority than library status.

Yes, I am considering a DIP on parametric-aliases at least, where I think C++ currently has an edge. Thanks for tipping me about those meetings, I didn't know one could apply for participation. That might be a possibility in the future, although I think I probably should try to find time to participate in those beer-meetings first to get a rough idea of what is achievable. No point in going to a formal meeting without knowing what the terrain is like. :-)

On Sunday, 6 February 2022 at 20:45:20 UTC, Ola Fosheim Grøstad wrote:

You've been replying directly to my posts.

If you intended to direct your messages at "the community" in general, rather than at me specifically, you should have started a new thread. As is, with these messages buried several pages deep in a thread about a different topic, most members of "the community" are unlikely to ever even read them in the first place.

On Sunday, 6 February 2022 at 20:52:21 UTC, Paul Backus wrote:

Good point. I will reread Robert's post on strategy and think about this for a while and write a more visible post when I have something that captures both Robert's concerns and concerns related to system level programming.

That said, I really wish you had talked more with C++ programmers who make use of modern C++ before writing the DIP. I am personally so used to adding [[nodiscard]] on all functions that it has become second nature. It is a very valuable feature in regards to refactoring I think, but also the most ill-conceived design in modern C++ (that I use). I might as well do a #define func [[nodiscard]].