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

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

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

>
a .= b;

This . is prone to be ambiguity.

December 31

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

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.