Jump to page: 1 2 3
Thread overview
How about `and` and `or` like in Python?
Oct 01
Murilo
Oct 01
Elronnd
Oct 01
Murilo
Oct 01
Murilo
Oct 01
mipri
Oct 01
Murilo
Oct 01
Murilo
Oct 01
Dennis
Oct 01
Murilo
Oct 02
Murilo
Oct 03
snow jhon
Oct 03
Dennis
Oct 04
Dennis
Oct 11
Murilo
October 01
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.
October 01
Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.
October 01
On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:
> Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.

But it could be an option, the current way would remain and this extra way would be added as an option.
September 30
On 9/30/2019 8:35 PM, Murilo wrote:
> On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:
>> Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.
> 
> But it could be an option, the current way would remain and this extra way would be added as an option.

C++ does this. Nobody uses it.
October 01
On Tuesday, 1 October 2019 at 04:06:17 UTC, Walter Bright wrote:
> On 9/30/2019 8:35 PM, Murilo wrote:
>> On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:
>>> Personally, I think this would make the code less readable; the current way creates more of a distinction between operators and operands.
>> 
>> But it could be an option, the current way would remain and this extra way would be added as an option.
>
> C++ does this. Nobody uses it.

Maybe they do and you just don't see it. I would use it. I believe that code should be as close to natural language as possible, that mindset is what lead Python to being so successful.
October 01
On Tuesday, 1 October 2019 at 04:34:59 UTC, Murilo wrote:
> I believe that code should be as close to natural language as
> possible, that mindset is what lead Python to being so
> successful.

If your argument isn't that *Perl's* application of this mindset
contributed to Python overtaking Perl, then there are a lot Larry Wall
speeches about language that you may enjoy :-)

What you're doing here is a "wouldn't you like to be popular, like
that language over there?" kind of appeal. It is, paradoxically, an
extremely hard argument to succeed at making. The reason is that 100k
variations of it will have already been heard by anyone you feel
comfortable making it to, so the argument has to be of an extremely
high standard to really be considered at all.

October 01
On Tuesday, 1 October 2019 at 05:15:47 UTC, mipri wrote:
> On Tuesday, 1 October 2019 at 04:34:59 UTC, Murilo wrote:
>> I believe that code should be as close to natural language as
>> possible, that mindset is what lead Python to being so
>> successful.
>
> If your argument isn't that *Perl's* application of this mindset
> contributed to Python overtaking Perl, then there are a lot Larry Wall
> speeches about language that you may enjoy :-)
>
> What you're doing here is a "wouldn't you like to be popular, like
> that language over there?" kind of appeal. It is, paradoxically, an
> extremely hard argument to succeed at making. The reason is that 100k
> variations of it will have already been heard by anyone you feel
> comfortable making it to, so the argument has to be of an extremely
> high standard to really be considered at all.

Man, you are making a whole philosophical speech about something tiny. I am just trying to explain that this would be good because it would make D richer since it would allow more readable code and give users more options.
October 01
On 2019-10-01 03:35:03 +0000, Murilo said:

> But it could be an option, the current way would remain and this extra way would be added as an option.

Less syntactic options is better than more. Code is read much more frequent than written. Hence, I don't want to have to learn zillions of different ways to express the same thing.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

October 01
On Tuesday, 1 October 2019 at 15:26:57 UTC, Robert M. Münch wrote:
> On 2019-10-01 03:35:03 +0000, Murilo said:
>
>> But it could be an option, the current way would remain and this extra way would be added as an option.
>
> Less syntactic options is better than more. Code is read much more frequent than written. Hence, I don't want to have to learn zillions of different ways to express the same thing.

Well, okay, I get your point, but it would be only one add-on, it wouldn't make it messy, and besides, if you want minimalism then perhaps you should stick to C instead, there you have very few ways of writing code. And again, my idea would make it EASIER to read cause it would be closer to natural language.
October 01
On Tuesday, 1 October 2019 at 19:23:00 UTC, Murilo wrote:
> if you want minimalism then perhaps you should stick to C instead, there you have very few ways of writing code. And again, my idea would make it EASIER to read cause it would be closer to natural language.

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:
- https://github.com/vibe-d/vibe.d/blob/c27f69dc9a17d969cbf394fa3b5947f8f7750ccf/web/vibe/web/auth.d#L342
- https://github.com/skoppe/spasm/blob/27717218bb64e10bab7a67511f87d4215bd2309c/source/spasm/ct.d#L868
- https://github.com/TurkeyMan/simd/blob/f04d4849dcd0b92b1d57b5a7974a9c686ff421e3/std/simd.d#L4516

Finally it opens the door for more "quality of life" synonyms, like `var` for `auto`, `boolean` for `bool`, angle brackets for template instantiations (yuck!), Java-like eponymous functions for constructors instead of `this()` etc.
« First   ‹ Prev
1 2 3