On Tuesday, 17 December 2019 at 22:14:32 UTC, aliak wrote:
> On Tuesday, 17 December 2019 at 10:14:35 UTC, Patrick Schluter wrote:
>> On Tuesday, 17 December 2019 at 09:20:06 UTC, Jacob Carlborg wrote:
>>>[...]
>> Yes, and that was the point of the exercice. Transforming the interpolated "string" into a string evaluates the values of the variables at the moment of that transformation. From then on, there is no interpolation possible as it a simple string.
>> I suppose that what aliak leant in his comments was that the string then could still be used for interpolation.
>>
>> [...]
>
> I'm pretty sure I said that I expect interpolated strings to be assignable to strings and that this DIP doesn't enable that. And people will need to understand tuples to understand what's happening. I'm not sure how you interpreted all the rest?

The question is, what is that string supposed to contain. The resolved interpolation ("apple = 0") or the interpolation string ("apple = $(apple)").

On Wednesday, 18 December 2019 at 01:20:33 UTC, Steven Schveighoffer wrote:
> [snip]
>
> BTW, people have been talking about usage like:
>
> auto str = i"I have $apples apples".format;
>
> And it got me thinking, does this actually work? I mean, can multiple parameters be used for UFCS?
>
> Answer: yes.
>
> auto str = AliasSeq!("I have %s apples", apples).format; // OK
>
> pretty cool. I had no idea.
>
> -Steve

I think it works because format takes a variadic template as an input. Given the connection between variadic templates and AliasSeq, the input is basically an AliasSeq in the first place. Shouldn't be an issue having AliasSeq's with length>1.

I don't know if I would describe it as multiple parameters. I would call UFCS with multiple parameters as describing when you have foo(x, y, z), you can call x.foo(y, z). In this case, something like
auto str = AliasSeq!("I have %s apples").format(apples);
also compiles without error and would be more comparable.

On 12/18/19 9:18 AM, jmh530 wrote:
> On Wednesday, 18 December 2019 at 01:20:33 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> BTW, people have been talking about usage like:
>>
>> auto str = i"I have $apples apples".format;
>>
>> And it got me thinking, does this actually work? I mean, can multiple parameters be used for UFCS?
>>
>> Answer: yes.
>>
>> auto str = AliasSeq!("I have %s apples", apples).format; // OK
>>
>> pretty cool. I had no idea.
>>
> 
> I think it works because format takes a variadic template as an input. Given the connection between variadic templates and AliasSeq, the input is basically an AliasSeq in the first place. Shouldn't be an issue having AliasSeq's with length>1.
> 
> I don't know if I would describe it as multiple parameters. I would call UFCS with multiple parameters as describing when you have foo(x, y, z), you can call x.foo(y, z). In this case, something like
> auto str = AliasSeq!("I have %s apples").format(apples);
> also compiles without error and would be more comparable.

Nope. Not just variadic templates:

assert(AliasSeq!(2, 2).pow == 4);

Not even templates in general:

int foo(int x, int y) { return x + y; }

assert(AliasSeq!(1, 2).foo == 3);

-Steve

On Wednesday, 18 December 2019 at 17:41:42 UTC, Steven Schveighoffer wrote:
> [snip]
>
> Nope. Not just variadic templates:
>
> assert(AliasSeq!(2, 2).pow == 4);
>
> Not even templates in general:
>
> int foo(int x, int y) { return x + y; }
>
> assert(AliasSeq!(1, 2).foo == 3);
>
> -Steve

Interesting.

On Wednesday, 18 December 2019 at 22:02:59 UTC, jmh530 wrote:
> On Wednesday, 18 December 2019 at 17:41:42 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> Nope. Not just variadic templates:
>>
>> assert(AliasSeq!(2, 2).pow == 4);
>>
>> Not even templates in general:
>>
>> int foo(int x, int y) { return x + y; }
>>
>> assert(AliasSeq!(1, 2).foo == 3);
>>
>> -Steve
>
> Interesting.

Please keep comments in this thread focused on the DIP. I've got to read through the whole thread for the summary. OT posts don't help. I'm going to start deleting OT posts from this point forward.

Thanks!

On 12/18/19 5:24 PM, Mike Parker wrote:
> 
> Please keep comments in this thread focused on the DIP. I've got to read through the whole thread for the summary. OT posts don't help. I'm going to start deleting OT posts from this point forward.
> 
> Thanks!

It's somewhat relevant because the usage case for tagging interpolated strings with .format requires this "feature", which I'm pretty sure was not intended.

In fact, when I first thought of it, I came here to post that we may need a language change, only to find out it works fine!

But sorry for the diversion.

-Steve

On Wednesday, 18 December 2019 at 17:41:42 UTC, Steven Schveighoffer wrote:
> On 12/18/19 9:18 AM, jmh530 wrote:
>> [...]
>
> Nope. Not just variadic templates:
>
> assert(AliasSeq!(2, 2).pow == 4);
>
> Not even templates in general:
>
> int foo(int x, int y) { return x + y; }
>
> assert(AliasSeq!(1, 2).foo == 3);
>
> -Steve

I introduce you to a D library I was working on a couple of years back:
https://gist.github.com/PetarKirov/a808c94857de84858accfb094c19bf77

;)

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

How are the following strings handled?

  i"hello $$name"  // double $

  i"hello $ name"  // no following identifier

  i"hello $"  // no following string

  i"hello \$name"  // escaped $

  i"hello $+name"  // invalid following character

(with the % -> $ change from a while back in the thread)

On Wednesday, 18 December 2019 at 22:24:05 UTC, Mike Parker wrote:
> Please keep comments in this thread focused on the DIP. I've got to read through the whole thread for the summary. OT posts don't help. I'm going to start deleting OT posts from this point forward.

So here is a general response:

1. There is no unity on what to expect from interpolated strings in the thread. That suggests that a library solution should be established first using D meta programming capabilities. Only when there is unity behind a library solution (and it is being used in practice) should it be considered as a candidate for syntactic sugar in the compiler.

2. What is missing in terms of metaprogramming capabilities to do this well as a library solution. That ought to be addressed before making any extension to the compiler.

3. How does adding non-critical features to the compiler impact the ability to move forward with critical features such as improved non-gc memory management. What should the priority of this feature be related to other more imporant features?

4. How does this feature impact the learnability of the language. Currently it seams that newbies become confused by language features (not only in D, but also in Rust and C++), so how can D improve on that situation? And how can the design of this feature contribute positively in that regard?

On 12/17/2019 6:19 AM, Alexandru Ermicioi wrote:
> I doubt someone will complain, about splitting object module into smaller packages based on performance reasons, and certainly splitting object.d won't trigger tens of files now. Though as said before it will increase readability. I personally can live with few more miliseconds for compilation time if readability is increased in druntime/phobos.

People often complain as DMD's compile speed steadily deteriorates. A few more milliseconds at a time add up.