bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: New append operators (was: Re: New conditional assignment facility)


From: rsbecker
Subject: RE: New append operators (was: Re: New conditional assignment facility)
Date: Sun, 28 Jan 2024 18:06:49 -0500

On Sunday, January 28, 2024 5:36 PM, Paul Smith wrote:
>On Sat, 2024-01-27 at 17:45 -0500, rsbecker@nexbridge.com wrote:
>> My take on it is that +:= (because of the : ) means that you have to
>> resolve everything at that point.
>
>Yes, I understand what you are saying.  The question is, is that the right 
>conception?
>Here's another way to look at it:
>
>    FOO +:= bar
>
>can be interpreted as working like this:
>
>    FOO := $(FOO) bar
>
>which is what you and others are arguing for.  Or it can be interpreted as 
>working
>like this:
>
>    __FOO := bar
>    FOO += $(__FOO)
>
>(where the value of __FOO is immutable).  This is what I was thinking.

I do not think the above two are equivalent. FOO += $(__FOO) will not be 
immutable until it is referenced. __FOO is immutable on the basis of the :=, 
but += is a lazy instantiation, by definition. Changing that semantic would 
have fairly broad impacts.

>My argument is, if you want to write "FOO := $(FOO) bar" you can just write 
>that
>today: you don't need "+:=" (you will have an extra leading space if FOO was 
>not set
>already but that's unlikely to matter much).
>
>But if you want the second form it's tricky to do.
>
>It can also be argued that the second form is closer to the behavior of "+=" 
>since
>"+=" keeps the pre-existing type of the variable rather than changing it.  
>Although of
>course it's still special in some respects.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]