On Tuesday, 1 October 2019 at 20:26:14 UTC, Dennis wrote:
> I used to program in a language (GML) that allowed both.
> I always preferred `not`, `and` and `or` over the symbols `!`, `&&` and `||`.
> That being said, adding the keywords when the symbols are already the standard is more harm than good.
>
> It creates more bikeshedding / style-guides / arguments over which is the preferred way. There already is enough discussion about "options" for brace styles, tabs/spaces, snake_case/camelCase etc.
>
> It also breaks existing code that uses these proposed keywords as identifiers.
> For example in fluent asserts, this is no longer valid when `not` is a keyword: `x.should.not.be(null);`
> Other examples:

Alright. That makes sense. But what about making it capitalized as And, Or and Not, that will not conflict with keywords.

On Tuesday, 1 October 2019 at 20:34:19 UTC, Murilo wrote:

>
> Alright. That makes sense. But what about making it capitalized as And, Or and Not, that will not conflict with keywords.

This has the same problem. You're introducing new keywords that will break any code using those words as identifiers.

What you're proposing has consequences. Aside from the potential for breakage, it adds complexity to the language. Opinions about improved readability and nicer aesthetics simply aren't strong enough to justify such a change (what gives your opinions more weight over those who disagree with you?).

Consider that when one person wanted to *remove* the keyword `body` as used in function contracts and replace it with another existing keyword, `do`, he wrote a DIP for it:

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md

And that's just to take something away from the language. You want to add something so that we'll have two ways of doing the same thing.

So a suggestion in the forums is not going to be the way to get this feature added. You'd need to write a DIP presenting a strong justification for the added complexity and the potential code breakage. And given the nature of the feature, I'd say you'd be fighting an uphill battle (meaning, I don't think there is a strong enough case to be made).

On Wednesday, 2 October 2019 at 03:18:56 UTC, Mike Parker wrote:
> So a suggestion in the forums is not going to be the way to get this feature added. You'd need to write a DIP presenting a strong justification for the added complexity and the potential code breakage. And given the nature of the feature, I'd say you'd be fighting an uphill battle (meaning, I don't think there is a strong enough case to be made).

Alright then.

On 10/1/2019 8:18 PM, Mike Parker wrote:
> So a suggestion in the forums is not going to be the way to get this feature added. You'd need to write a DIP presenting a strong justification for the added complexity and the potential code breakage. And given the nature of the feature, I'd say you'd be fighting an uphill battle (meaning, I don't think there is a strong enough case to be made).

As I mentioned, C++ has them:

https://en.cppreference.com/w/cpp/language/operator_alternative

https://www.reddit.com/r/cpp/comments/4h5lsb/why_arent_alternative_operators_more_common/

Adopting failed ideas from other languages is a pretty tough sell. One can always write a DIP, but I don't see a path for adoption for such a feature.

On Wednesday, 2 October 2019 at 20:16:12 UTC, Walter Bright wrote:
> On 10/1/2019 8:18 PM, Mike Parker wrote:
>> So a suggestion in the forums is not going to be the way to get this feature added. You'd need to write a DIP presenting a strong justification for the added complexity and the potential code breakage. And given the nature of the feature, I'd say you'd be fighting an uphill battle (meaning, I don't think there is a strong enough case to be made).
>
> As I mentioned, C++ has them:
>
> https://en.cppreference.com/w/cpp/language/operator_alternative
>
> https://www.reddit.com/r/cpp/comments/4h5lsb/why_arent_alternative_operators_more_common/
>
> Adopting failed ideas from other languages is a pretty tough sell. One can always write a DIP, but I don't see a path for adoption for such a feature.

For some reason that syntax confuses me:

cout << true and false;

This prints out 1 in c++, but I read it as "cout << (true and false)".

Instead cout << true && false sounds to me like (cout << true) && false.

On Tuesday, 1 October 2019 at 20:26:14 UTC, Dennis wrote:
> On Tuesday, 1 October 2019 at 19:23:00 UTC, Murilo wrote:
>> [...]
>
> I used to program in a language (GML) that allowed both.
> I always preferred `not`, `and` and `or` over the symbols `!`, `&&` and `||`.
> That being said, adding the keywords when the symbols are already the standard is more harm than good.
>
> [...]

Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.

On Thursday, 3 October 2019 at 22:53:55 UTC, snow jhon wrote:
> Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.

With a syntax highlighter that makes them bold you don't have this problem.

Also, && and || are actually pretty exceptional operators. Most operators are simply functions mapping directly to hardware instructions with special symbol notation. In D they can be overloaded using functions opBinary or upUnary. && and || have lazy evaluation and therefor introduce control flow unlike functions whose parameters are evaluated first.

Zig is designed in such a way that all control flow happens through keywords. The bitwise and/or functions use the & and | symbols, but boolean and/or use the keywords [1]. (Also the ternary operator is just `if` and `else` forming an expression instead of a statement.)

This gives an actually useful distinction between keywords and symbols. But like I said, trying to change D on that aspect at this point is not useful.

[1] https://ziglang.org/documentation/0.5.0/#Operators

On 10/3/2019 4:35 PM, Dennis wrote:
> With a syntax highlighter that makes them bold you don't have this problem.

Language design that relies on a syntax highlighter is not good. An awful lot of print media is still black-on-white, for example.

On Friday, 4 October 2019 at 03:46:30 UTC, Walter Bright wrote:
> On 10/3/2019 4:35 PM, Dennis wrote:
> Language design that relies on a syntax highlighter is not good. An awful lot of print media is still black-on-white, for example.

Even on my typewriter I can make words bold, no color is needed. ;)

On Tuesday, 1 October 2019 at 00:47:57 UTC, Murilo wrote:
> In Python the && operator is `and` just like the || operator is `or`. How about giving D this option? People could choose to use either of those forms. I am suggesting you create the `and` and `or` keywords to represent && and ||, respectively. That should make the code more readable.

bool and(bool a, lazy bool b) { return a && b; }

if (cond1.and(cond2)) {
    // ...
}

Implementation of `or` is left as an exercise for the reader. :)