Replacing percent signs

[Helgef]

+1 @nnnik

[HotKeyIt]

{x:x,y:y,w:w,h:h} seems like the best candidate for that.

I think you rather meant %{x:x,y:y,w:w,h:h} but how are you going to add spaces when the output should be x10 y10 w10 h10?

[Helgef]

Hotkeyit, I'm not speaking for nnnik here, but although I was taking about strings, my guess is that nnnik meant for that to be an associative array, specifying some dimensions, which in true ahk fashion usually is done with a string like I exemplified. Cheers.

[nnnik]

Yep you are right Helgef

[lexikos]

At some point there was a string variable interpolation syntax, but that was removed. Presumably this was due to the fact that Format is superior and should be used instead. However some popular languages do have variable interpolation as a way to cut down on syntactic noise stemming from repeated concat operators. If variable interpolation in strings is reintroduced then we can get rid of auto-concat, which can be seen as kludgy syntax that results in unexpected/unintuitive results (Function(Param) works, Function (Param) does not).

(I figured it would be better to continue the discussion here than to reply in the above topic.)

As you know, percent signs were already - and still are in v1 - used for variable interpolation in unquoted text. Allowing the same syntax in quoted strings brought a little uniformity. Some users already tried to use "%var%", so allowing it removed one minor cause of confusion.

In v1, that percent signs have a different effect in unquoted text than in an expression is a source of confusion (even though the meaning of characters written directly in the source code depends on context in exactly the same way). I suppose that users associate percent signs with variables rather than with substitution. Hypothetically, if all text was quoted but percent-substitution was permitted, the problem would still be present, since percent signs still have the exact same effects dependent on context. In order for the removal of commands to be worthwhile, I figured that percent-substitution in quoted strings had to be removed as well.

So no, it was not removed due to any superiority of Format, but because the primary reason for adding it was invalidated and because it would have been a source of confusion.

I have also been reconsidering percent-sign derefs in quoted strings, as they were primarily an attempt at integrating the "legacy" syntax with expressions and bringing more consistency to the language. Though I'm reluctant to deviate from the v1 expression syntax, I think there are more readable alternatives for variable/expression substitution within strings.

I have long felt that all of the changes I made to command syntax (up to the current build) were inadequate; despite the cost (to compatibility), they would not eliminate the confusion users have with percent signs or make the syntax easier to learn, and the language and documentation are still (or would be) unnecessarily complicated.

My current feeling is that removing percent sign derefs is along the same lines as removing command syntax. Percent-derefs are (debatably) more readable and/or convenient, like command syntax. They are entirely redundant, like command syntax. There are still different meanings of %, so it doesn't eliminate the risk of users mistakenly using percent signs where they aren't needed. Basically, %variable% derefs must go.

The other reason for percent-substitution in quoted strings was (ostensibly) that it is sometimes more readable than concatenation. However, I found that there were still many cases where I preferred to use auto-concat. There were always other possibilities, but being a natural extension of existing syntax gave percent-substitution more appeal. That no longer applies.

I presented some other ideas in this topic already.

Python 3.6 has "F-strings", much the same as string interpolation in C#, but with F instead of $.

[fincs]

Thanks for the explanation, I now understand better the rationale behind removing %% syntax in strings. Having a special format-string syntax like the one in Python or C# that ties directly with format() is probably a better solution indeed.

[sirksel]

+1 for F-strings.