Thread overview
binary dot assignment
Dec 30, 2024
Basile B.
Dec 31, 2024
zjh
Dec 31, 2024
Basile B.
Jan 01, 2025
claptrap
Jan 21
IchorDev
Jan 21
monkyyy
December 30, 2024

If you look long enough at some code you'll see patterns like

a = a.b;

this pattern strangely looks like binary assignment operators

a = a + b;

which can be rewritten as

a += b;

In the same fashion we could have

a .= b;

The point is to evaluate te left hand side only once.

December 31, 2024

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>
a .= b;

This . is prone to be ambiguity.

December 31, 2024

On Tuesday, 31 December 2024 at 01:18:34 UTC, zjh wrote:

>

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>
a .= b;

This . is prone to be ambiguity.

.= would be a whole token. I already use this in styx since several monthes:

img

January 01, 2025

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>

If you look long enough at some code you'll see patterns like

a = a.b;

this pattern strangely looks like binary assignment operators

a = a + b;

which can be rewritten as

a += b;

In the same fashion we could have

a .= b;

The point is to evaluate te left hand side only once.

Too much syntax sugar will lead to cavities.

January 21

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>

If you look long enough at some code you'll see patterns like

a = a.b;

this pattern strangely looks like binary assignment operators

a = a + b;

which can be rewritten as

a += b;

In the same fashion we could have

a .= b;

The point is to evaluate te left hand side only once.

It’s a nice idea but it doesn’t help with the similar and perhaps more commonly used pattern slice = slice[1..$]. Is there any way we could redesign the syntax so it works for any case of Identifier = Identifier Expression?

January 21

On Tuesday, 21 January 2025 at 20:55:34 UTC, IchorDev wrote:

>

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>
a .= b;

It’s a nice idea but it doesn’t help with the similar and perhaps more commonly used pattern slice = slice[1..$]. Is there any way we could redesign the syntax so it works for any case of Identifier = Identifier Expression?

auto pop(R)(R r)=>r[1..$];
slice.=pop;

?

February 12

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>

If you look long enough at some code you'll see patterns like

a = a.b;

this pattern strangely looks like binary assignment operators

a = a + b;

which can be rewritten as

a += b;

In the same fashion we could have

a .= b;

The point is to evaluate te left hand side only once.

I'm not sure .= (and other options?) occurs often enough for this to be worth it.

February 13

On Monday, 30 December 2024 at 21:33:58 UTC, Basile B. wrote:

>

If you look long enough at some code you'll see patterns like

a = a.b;

this pattern strangely looks like binary assignment operators

a = a + b;

which can be rewritten as

a += b;

In the same fashion we could have

a .= b;

The point is to evaluate te left hand side only once.

It will fool newcomers into thinking . is a binary operator, but it’s not. The right-hand side cannot ever be something other than an Identifier followed by something. I don’t think I have ever seen someone put spaces around . exactly because of that.

February 15
> I'm not sure `.=` (and other options?) occurs often enough for this to be worth it.

Yes. Need more information on how common this pattern is.

Note that the compiler doesn't evaluate the lvalue twice unless it has side effects.