February 08, 2022
On Tuesday, 8 February 2022 at 21:28:06 UTC, claptrap wrote:
>
> Probably @noignore would be a better name. You're not really trying to dictate what people do with the result, just that they dont ignore it.

I'd like to see an option to annotate such an attribute. Something like this:

@mustuse("or else this could occur")

Then the compiler could return that message, rather than some generic message that provides no real insight into why that attribute was used in the first place.

Similar to C++20's: [[nodiscard("check if not null")]])

February 09, 2022

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

>
  1. The politics of language improvements: I don't think this should be a library type. I think this feature is too important for that. To me this smells of let's move the syntax to a library to avoid any discussion about breaking changes. Design considerations should not become political, we need to get rid of politics and focus on principled strategies that makes the whole eco system attractive to more developers (the ones we don't have).

This is a disrespectful comment. You're implying that your opinion is rational and apolitical, disagreeing with it is irrational politics. It is true that no decisions are fully politics-free, but please don't pretend that you are above all others here in that regard.

February 09, 2022

On Wednesday, 9 February 2022 at 10:59:03 UTC, Dukc wrote:

>

You're implying that your opinion is rational and apolitical, disagreeing with it is irrational politics.

I am implying that there are many symptoms of people not being willing to champion the best possible design and instead have started to look for what they think is easy to get through. I see that in this DIP, in other DIPs and in comments about DIPs people are contemplating. The accumulated outcome of such political design processes are usually not great.

I will later try to create a separate thread for this, as Paul does not want this topic in this thread.

February 09, 2022
On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
> First, I'm not 'insisting' on anything. I'm just expressing a view.
>
> nodiscard is already used by more programmers that D is likely to ever adopt.
>
> Indeed, it's these programmers that D is trying to adopt.
>
> I'm not sure forcing such people to adapt is necessarily the right approach.
>

I'll have to side with forkit there.

In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized.

If you call your "Amount" parameter "Dry/wet" instead, then misunderstandings will happen for years without ever a chance to correct them, because "Dry/wet" means something already in the users mind.

If you call your mutex a "synchronizer" then you have to tell everyone what is a synchronizer, why it is needed as a concept, and so on. Think: "slices" and "dynamic arrays" in D, a distinction that is of no use and begets a lot of misunderstandings.

Hence some does of of reusing, reduce mental load. Paucity of words helps the cast of D explainers.
February 09, 2022
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat wrote:
>
> Hence some does of of reusing,

some dose of reuse*
February 09, 2022
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat wrote:
> On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
>> First, I'm not 'insisting' on anything. I'm just expressing a view.
>>
>> nodiscard is already used by more programmers that D is likely to ever adopt.
>>
>> Indeed, it's these programmers that D is trying to adopt.
>>
>> I'm not sure forcing such people to adapt is necessarily the right approach.
>>
>
> I'll have to side with forkit there.
>
> In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized.

In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid.

In other languages, there are multiple existing words:

- C++17: [[nodiscard]]
- C (gcc/clang): __attribute__((warn_unused_result))
- Rust: #[must_use]

If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word.

And, of course, if you are used to Python or Javascript or one of the many other languages that has no word for this at all, it will make little difference to you either way.

C++ is quite popular, but it is not the only popular language, and there are many D programmers who have never used C++ at all, let alone C++17 or later. Therefore, it is a mistake to assume that all or even most D programmers have already internalized "nodiscard", or indeed *any* particular word for this concept.
February 09, 2022
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
> [snip]
>
> In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid.
>
> In other languages, there are multiple existing words:
>
> - C++17: [[nodiscard]]
> - C (gcc/clang): __attribute__((warn_unused_result))
> - Rust: #[must_use]
>
> If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word.
>

But what color should the bike shed be? ;)
February 09, 2022
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
> C++ is quite popular, but it is not the only popular language, and there are many D programmers who have never used C++ at all, let alone C++17 or later. Therefore, it is a mistake to assume that all or even most D programmers have already internalized "nodiscard", or indeed *any* particular word for this concept.

There is also the Nim "discard" statement. I wonder why noone stole that feature. Feels more natural to me speak about the error being avoided, than a vague statement like "must use". C++17 is the most used language in the native space, so yes I think it takes precedence in the minds of native programmers. But, it is a level of bikeshedding I'm not keen on entering.

February 10, 2022
On 10/02/2022 5:21 AM, Paul Backus wrote:
> - C (gcc/clang): __attribute__((warn_unused_result))

C23 will also have [[nodiscard]]

Not only will it have that on functions, but also support a string too.

Unfortunately its looking like we have chosen to diverge from C, and therefore won't be completely C compatible soon.

Will be exciting as to what kind of bugs crop up because of this!
February 09, 2022
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
> On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat wrote:
>> On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
>>> First, I'm not 'insisting' on anything. I'm just expressing a view.
>>>
>>> nodiscard is already used by more programmers that D is likely to ever adopt.
>>>
>>> Indeed, it's these programmers that D is trying to adopt.
>>>
>>> I'm not sure forcing such people to adapt is necessarily the right approach.
>>>
>>
>> I'll have to side with forkit there.
>>
>> In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized.
>
> In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid.
>
> In other languages, there are multiple existing words:
>
> - C++17: [[nodiscard]]
> - C (gcc/clang): __attribute__((warn_unused_result))
> - Rust: #[must_use]
>

C++17: [[nodiscard]] is just a warning; must use another compiler flag in order to have same @mustuse in D -> already discrepancy in meaning