December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sebastiaan Koppe | On Wednesday, 11 December 2019 at 11:05:25 UTC, Sebastiaan Koppe wrote:
> - I know it is bikeshedding but since string interpolation is 99% syntax, I vote for "either a single $colon for variables or ${expression} for expressions", like literally every other modern language.
That's definitely not bikeshedding. Given how late D is to the party on this, there's no excuse to not steal the best available syntax from other languages.
|
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Tschierschke | On Wednesday, 11 December 2019 at 12:11:34 UTC, Martin Tschierschke wrote:
> Yes +1! It should be something common, not a dlang only syntax.
> => $var and ${expression}
>
> https://en.wikipedia.org/wiki/String_interpolation
>
> But this alone gives no way for formatting numbers, so maybe ${%9.6f}{fvar} ?
My recollection is that in Python 3 that would be done {fvar: 9.6f} or something like that (not a Python programmer).
|
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On Wednesday, 11 December 2019 at 14:41:39 UTC, jmh530 wrote:
> This %(name) is probably the closest that compares to this DIP, but it seems like the Python 3.6 string interpolation was meant to replace that.
Yes, I no longer use % in Python. It is baggage. I either use format or f"…".
A good reason to aim for modern Python is that newbies will know it. Python is taught in universities... It will look familiar to the next batch of programmers.
|
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to bachmeier | On Wednesday, 11 December 2019 at 14:55:08 UTC, bachmeier wrote: > [snip] > > My recollection is that in Python 3 that would be done {fvar: 9.6f} or something like that (not a Python programmer). Python's formatting is described here: https://www.python.org/dev/peps/pep-0498/#id30 so I think it would be more like {var: {9}.{6}} Scala's would be more like $val%9.6f, which I find both more concise and consistent with other D code. |
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Wednesday, 11 December 2019 at 14:59:27 UTC, Ola Fosheim Grøstad wrote:
> [snip]
> Yes, I no longer use % in Python. It is baggage. I either use format or f"…".
>
> A good reason to aim for modern Python is that newbies will know it. Python is taught in universities... It will look familiar to the next batch of programmers.
Please see my reply above to bachmeier on Python's format strings versus Scala's.
Because of the formatting options, I wouldn't lean too heavily on Python's syntax. I think we should look to what other languages do, but ultimately do what is right for D and consistent with the language that is already there.
|
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On Wednesday, 11 December 2019 at 15:13:20 UTC, jmh530 wrote: > Because of the formatting options, I wouldn't lean too heavily on Python's syntax. I think we should look to what other languages do, but ultimately do what is right for D and consistent with the language that is already there. Sure, but as I pointed out you can do both. Just upgrade "%d" and "%f" to formatting objects and rewrite them. So, if you want oldstyle you just write f"%...d{variablename}" and it will be turned into f"{std.formatter.format_d(…), variablename}" Having formatting objects is important for many reasons, one is localization. You need that for float and ints. "3,14" vs "3.14" or "1,000,000" vs "1'000'000" etc. So you can do: auto d = some_custom_formatter(…) f"{d, variablename}...{d, somothervariable}" *shrug* printf style is only useful for logging and text file formats. It does not work for GUIs or anything that is user facing. You need to be able to customize and provide your own formatters. (Just think currency "100 USD" vs "100 SEK") |
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote: The transformation is WRONG! '%%', a '%' is written to the output string. it must be '%%', a '%%' is written to the output string or else you will have problems Example. If I have following expression writefln(i"I ate %{d}apples and %{d}bananas totalling %{d}(100*apples/bananas) %%fruit\n"); it would be lowered to writefln("I ate %d and %d totalling %d %fruit\n", apples, bananas, (100*apples/bananas)); The %% being transformed to a simple %, we now have a %f with no parameter => compilation error or worse undefined behaviour in case of printf. I would have to write writefln(i"I ate %{d}apples and %{d}bananas totalling %{d}(100*apples/bananas) %%%%fruit\n"); which is not good. So '%%' have to be untouched by the lowering |
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alexandru Ermicioi | On Wednesday, 11 December 2019 at 10:57:13 UTC, Alexandru Ermicioi wrote:
> On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
>> [...]
>
> Why not just split interpolated string into just a tuple of args & strings. For example:
> Given: (i"I ate %apples and %bananas totalling %(apples + bananas) fruit.")
> Is lowered to a tuple: ("I ate ", apples, " and ", bananas," totalling ", apples + bananas," fruit.")
>
> It seems current version unnecessarily ties to printf formatting syntax, and makes harder for them to be used in custom user code.
>
> Also user still needs call a function to get assembled string which differs from what other languages are doing with interpolated strings.
>
This wouldn't work for C formats like printf. The proposition has the nice property of being usable for DasBetterC and interfacing with C libraries that use format specifiers (libxml2 anyone?).
|
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to rumbu | On Wednesday, 11 December 2019 at 11:35:05 UTC, rumbu wrote: > On Wednesday, 11 December 2019 at 11:00:12 UTC, MrSmith wrote: >> On Wednesday, 11 December 2019 at 10:48:56 UTC, Rumbu wrote: >>> So we cannot have variables named d, s, f, g, x and so on because they are standard format specifiers. What happens with custom format specifiers, any one letter variable cannot be interpolated? >> >> According to proposal you would wrap format specifiers into {}, like i"%{d}bananas" > > Nope, that means "use %d format specifier to print number of bananas". According to the DIP, this is invalid: No. Read the grammar. Format specifiers MUST be in {}. Element: Character '%%' '%' Argument '%' FormatString Argument FormatString: '{' FormatString '}' CharacterNoBraces CharacterNoBraces: CharacterNoBrace CharacterNoBrace CharacterNoBraces CharacterNoBrace: characters excluding '{' and '}' characters does not exclude s, d, f, g etc. > > string what = "bread"; > int d = 10; > writefln(i"making %what using %d ingredients"); which is transformed in writefln("making %s using %s ingredients", what, d); |
December 11, 2019 Re: DIP 1027---String Interpolation---Community Review Round 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rumbu | On Wednesday, 11 December 2019 at 12:35:54 UTC, Rumbu wrote:
> On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1027, "String Interpolation":
>>
>> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
>>
>> writefln(i"I ate %apples and %{d}bananas")
>
> What if I don't want any space after %apples?
Then you write %(apples)nospace.
|
Copyright © 1999-2021 by the D Language Foundation