On 8/14/24 20:27, IchorDev wrote:
> On Wednesday, 14 August 2024 at 14:48:42 UTC, user1234 wrote:
>> Well, just wanna say that this is an easy check to implement in Dscanner. That does not require any context. Just match the pattern in the AST and issue a warning.
> 
> Sounds like a better idea to do that. I’m not a fan of having more ‘it’s unintuitive therefore we’ll force the code to be unreadable’ features like bitwise operators requiring parenthesisation.

I can't say I ever wanted `a & b==c`.

Anyway, this is indeed the same kind of thing, and it would be consistent to ban this case too.

On 8/13/24 22:30, IchorDev wrote:
> On Tuesday, 13 August 2024 at 10:14:29 UTC, Timon Gehr wrote:
>> A bug that crops up now and then in D is that someone negates `a == b` by prepending a `!`. The result is `!a == b`. This parses as `(!a) == b` and will often silently do the wrong thing because negation implies cast to `bool`, and `bool` can be compared with integral types and `enum` members.
>>
>> I think it would be better for this to give a diagnostic and require explicit parentheses, similar to bitwise operators (where the operator precedence is unintuitive in the other direction).
> 
> Doesn’t require a DIP, but I’ve also never seen anyone think this would work?

The main issue is this is a typo that indeed happens now and then, not that people would think it works.

E.g., when you have:

`foo() || function_call_long_name() == c`

Now you negate the entire thing:

`!(foo() || function_call_long_name() == c)`

Now you think it would be more readable with individual negations.

!foo() && !function_call_long_name() == c`

This could easily happen, particularly if you are tired and you write a lot of Python.

Now you compile and it does not work. If you test well enough, you'll notice it. You debug for a few minutes and eventually come across this part of the code again and notice the mistake. This could all be dealt with a bit more efficiently.

> Do we really need to pander to people who don’t even understand that logical operators only *return* `bool`?

That's a strawman, and a bit insulting to anyone who has made this particular typo.

> Maybe that seems harsh, but I have never even thought of doing this because it’s just so obviously wrong—if I wrote it then I must have meant what I wrote, and I was probably happy with how it looked too.

Your elitist attitude is somewhat common and I think used to make similar (if somewhat less strong) statements 10 years ago, but I think it was not particularly wise. In the end, most code you'll run is not written by you. And most readers of your code do not want to read `!a==b`.

> Having to wrap it in parenthesis would just negate that and add to my code’s parenthesis hell.
> 
> P.S. this isn’t a bug;

This is a DIP idea, not a bug report.

> and `!` is ‘logical not’, not ‘negation’.

Those are in fact synonyms.
https://en.wikipedia.org/wiki/Negation

On Tuesday, August 13, 2024 4:14:29 AM MDT Timon Gehr via dip.ideas wrote:
> A bug that crops up now and then in D is that someone negates `a == b` by prepending a `!`. The result is `!a == b`. This parses as `(!a) == b` and will often silently do the wrong thing because negation implies cast to `bool`, and `bool` can be compared with integral types and `enum` members.
>
> I think it would be better for this to give a diagnostic and require explicit parentheses, similar to bitwise operators (where the operator precedence is unintuitive in the other direction).

I don't think that I have ever seen anyone do something like !a == b with any type other than bool, and it would be annoying if it were disallowed for bool. So, I don't really think that such a change would be particularly valuable, but I also wouldn't particularly care if it were made an error in cases where the types involved aren't bool. It wouldn't affect code that I would write, and if it fixed the occasional bug, then that's arguably a good thing. However, I definitely would rather not see this become an error for bool.

- Jonathan M Davis

ollama run mistral-large
>>> """
The following message was sent to a board of the D programming language discussing language improvement ideas:

Subject: Deprecate `!a == b`
Body:
A bug that crops up now and then in D is that someone negates `a == b` by prepending a `!`. The result is `!a == b`. This parses as `(!a) == b` and will often silently do the wrong thing because negation implies cast to `bool`, and `bool` can be compared with integral types and `enum` members.

I think it would be better for this to give a diagnostic and require explicit parentheses, similar to bitwise operators (where the operator precedence is unintuitive in the other direction).


Using simple English, as unambiguously as possible and adding helpful context, please explain what this message is trying to say.
"""
The message is suggesting an improvement for the D programming language. Specifically, it points out a common mistake where programmers write `!a == b` instead of `!(a == b)`. This can lead to bugs because `!a == b` is interpreted as `(!a) == b`, which might not be what the programmer intended and could silently cause errors. The message suggests that the language should issue a warning or error when it encounters this pattern, requiring explicit parentheses to avoid confusion. This would help prevent bugs and make code more reliable by ensuring that programmers are clear about their intentions.

>>> Is the message suggesting that there is a bug in the language itself?
No, the message is not suggesting that there is a bug in the D programming language itself. Instead, it is highlighting a common mistake that programmers might make due to the way certain expressions are parsed and evaluated in the language. Specifically, when someone writes `!a == b`, they often mean `!(a == b)` but forget to include the parentheses, leading to unexpected behavior because D interprets it as `(!a) == b`.

The message is proposing a change that would help prevent this kind of mistake by making the language issue a diagnostic (such as a warning or error) in such cases. This would encourage programmers to write their expressions more explicitly, reducing the likelihood of unintended behavior and potential bugs in their code.

>>> What is the message trying to bring across when it says "someone negates `a == b` by prepending a `!`" ?
The phrase "someone negates `a == b` by prepending a `!`" refers to the common mistake where a programmer intends to negate the result of an equality comparison but does so incorrectly. Specifically, instead of writing `!(a == b)`, which correctly negates the entire expression `a == b`, they write `!a == b`.

Here’s what happens in this case:
- The programmer intends to check if `a` is not equal to `b`.
- They mistakenly write `!a == b` instead of `!(a == b)`.
- In D, the expression `!a == b` is parsed as `(!a) == b`, which means:
  - First, `a` is negated (which can involve a type conversion to `bool`).
  - Then, this boolean result is compared with `b`.

This mistake can lead to bugs because the expression does not do what the programmer intended. The message is suggesting that the language should issue a diagnostic in such cases to help catch these mistakes early and make it clearer how expressions are being interpreted by the compiler.

>>> What is the relationship between the words "negate" and "logical not"?
In the context of programming, the terms "negate" and "logical NOT" are closely related but can have slightly different nuances depending on the specific usage:

1. **Negate**:
   - To negate something generally means to invert its meaning or value.
   - In a broad sense, negation can apply to various types of values (e.g., arithmetic negation for number
numbers) and logical operations.
   - When applied specifically to boolean values, negating a condition typically involves changing `true`
to `false` and vice versa.

2. **Logical NOT**:
   - Logical NOT is a specific type of negation that applies strictly to boolean (logical) values.
   - It reverses the truth value of a logical expression or condition. For example, if `x` is `true`, then
then `!x` will be `false`.
   - In many programming languages, including D, the exclamation mark (`!`) is used as the logical NOT ope
operator.

In summary, "negate" can refer to a general concept of reversing or denying something, while "logical NOT" specifically refers to the operation that inverts boolean values using the `!` operator. In the context of the original message, "negating `a == b` by prepending a `!`" means applying the logical NOT operation to the result of the equality comparison (i.e., turning `true` into `false` and vice versa).

>>> Why would someone choose to use the verb "negate" instead of the phrase "invert the boolean value using the logical not operator"?
Someone might choose to use the verb "negate" instead of the phrase "invert the boolean value using the logical NOT operator" for several reasons:

1. **Conciseness**:
   - The term "negate" is shorter and more concise than "invert the boolean value using the logical NOT operator." This can make communication quicker and easier to read, especially in contexts where brevity is important, such as technical discussions or documentation.

2. **Familiarity**:
   - The term "negate" is commonly used in mathematical and logical contexts, so it may be more immediately recognizable and familiar to many programmers and mathematicians. It conveys the general idea
of reversing a value or condition without needing additional explanation.

3. **Broad Applicability**:
   - "Negate" can be used in a broader range of contexts, including arithmetic negation (e.g., `-x` for numbers) and logical negation (e.g., `!x` for booleans). This versatility makes it a useful term when discussing different types of operations that involve reversing values or conditions.

4. **Simplicity**:
   - Using "negate" can simplify the language used in explanations, making them more accessible to readers who may not be familiar with specific programming terminology like "boolean value" and "operator." It provides a clear and straightforward way to describe the action without getting into the technical details.

In summary, using "negate" is often preferred because it is concise, familiar, broadly applicable, and simple, making communication more efficient and accessible.

>>> Send a message (/? for help)

On 8/16/24 17:48, IchorDev wrote:
> On Thursday, 15 August 2024 at 16:12:50 UTC, Timon Gehr wrote:
>> I can't say I ever wanted `a & b==c`.
> 
> In my dreams:
> ```d
> if(x & Flags.flag && y & Flags.flag){
>    //…
> }
> ```

Well, your dreams are true. This works.

> But reality we just put a bandage of frustration over C’s mistakes.

To some extent, but that's just what you get from C-inspired languages.