January 28, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Thursday, 28 January 2021 at 20:37:46 UTC, Kagamin wrote:
> Whoa, this looks impossible to lex.
It's not.
Please everyone, if you are going to leave a comment, leave a substantive explanation too.
|
January 28, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On 1/28/2021 12:34 PM, 12345swordy wrote:
> That being said. Would it be easier to convince you to accept this if there is a prototype version of this?
Prototype of a way to call printf, or prototype of the DIP?
|
January 28, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 1/28/2021 6:42 AM, Steven Schveighoffer wrote:
> On 1/28/21 1:12 AM, Walter Bright wrote:
>> It appears to have abandoned being usable with printf?
>
> Yes and no.
>
> Yes, we do not think that using printf with interpolated strings *without modification* is an important goal. printf works fine as it is. This is D, not C. writeln IS usable without modifications.
>
> And no, it is not abandoned, because it's perfectly possible because of the awesome power of metaprogramming allowed in this DIP:
>
> https://run.dlang.io/is/X5HcXS
Interesting, but it's really writing your own printf, and one that doesn't accept any format modifiers.
|
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Friday, 29 January 2021 at 04:25:54 UTC, Walter Bright wrote:
> Interesting, but it's really writing your own printf, and one that doesn't accept any format modifiers.
It is trivial to accept format modifiers here too, his example just generated them from type info because you can.
It could just as well be
printf(i"%s${item} %02d${other_item}");
which expands to the inlinable call
printf("%s %02d", item, other_item);
by means of simple metaprogramming (you concat the strings at compile time - no runtime cost, it reduces to an eponymous template with an enum string - then build the call out of the remaining filtered tuple).
You can even do a CTFE scan of the string if you like and see that there's a % already and use it, or there isn't one and insert one.
While this is an overload to do the CTFE manipulations, they are indeed CTFE manipulations and thus have no runtime footprint; it reduces to an inlined call to the original thing. Same assembly.
D excels at these things.
|
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | Comparing two simple examples of #DIP1036 and #DIP1027: DIP1036: printf(i"%s${item} %02d${other_item}"); // metaprogramming + printf overload DIP2027: printf(i"$item ${%02d}other_item"); // direct DIP1036: writeln(i"I ate ${apples} apples and ${bananas} bananas totaling ${apples + bananas} fruit."); DIP1027: writefln(i"I ate $apples apples and $bananas bananas totaling $(apples + bananas) fruit."); DIP1036 is more user typing, including awkward-to-type { }, along with needing substantial user code to implement (for printf). DIP1027's syntax is optimized to make the most common cases the simplest for the user, no user code is required. |
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 1/28/2021 8:47 PM, Adam D. Ruppe wrote:
> D excels at these things.
Ok, it's doable, but it's writing your own printf to do these manipulations.
|
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 29/01/2021 9:02 PM, Walter Bright wrote:
> On 1/28/2021 8:47 PM, Adam D. Ruppe wrote:
>> D excels at these things.
>
> Ok, it's doable, but it's writing your own printf to do these manipulations.
I agree, we shouldn't need to write the mapper function which Steven wrote ourselves.
We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility.
|
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | On 1/29/2021 12:46 AM, rikki cattermole wrote: > I agree, we shouldn't need to write the mapper function which Steven wrote ourselves. > > We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility. Even if it becomes part of Phobos, overloading C functions imported from external C libraries in general makes me uncomfortable, because it hides the fact that the C function isn't being called. I never liked C macros like: #define printf(...) printf("abc" ...) for the same reason. |
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Friday, 29 January 2021 at 08:57:13 UTC, Walter Bright wrote: > On 1/29/2021 12:46 AM, rikki cattermole wrote: >> I agree, we shouldn't need to write the mapper function which Steven wrote ourselves. >> >> We (Steven and I) discussed this on Discord and left it at the function should not be included in the DIP. From a UX POV, it should be just a matter of doing an alias IMO. But that isn't really a goal of a DIP to specify such utility. > > Even if it becomes part of Phobos, overloading C functions imported from external C libraries in general makes me uncomfortable, because it hides the fact that the C function isn't being called. I never liked C macros like: > > #define printf(...) printf("abc" ...) > > for the same reason. Would a pragma i.e. pragma(rewriteStringIntoFormatVarargs) extern(C) int printf(const char* fmt, ...); Make you feel more comfortable with this DIP? This way only functions which the binding creator says fall into this style can be called via a interpolated string correctly. Without any overloads or anything else. |
January 29, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | On 1/29/2021 1:15 AM, Rikki Cattermole wrote:
> Would a pragma i.e.
>
> pragma(rewriteStringIntoFormatVarargs)
> extern(C) int printf(const char* fmt, ...);
>
> Make you feel more comfortable with this DIP?
>
> This way only functions which the binding creator says fall into this style can be called via a interpolated string correctly. Without any overloads or anything else.
The more special cases there are, the more unwieldy the language becomes, and the more unexpected interactions and unforeseen bugs.
|
Copyright © 1999-2021 by the D Language Foundation