Jump to page: 1 2 3
Thread overview
Feedback Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2
Jan 27, 2021
Mike Parker
Jan 27, 2021
jmh530
Jan 27, 2021
jmh530
Jan 27, 2021
Atila Neves
Jan 28, 2021
Walter Bright
Jan 28, 2021
Walter Bright
Jan 28, 2021
Dukc
Jan 28, 2021
Dukc
Jan 28, 2021
Dukc
Jan 28, 2021
Kagamin
Jan 28, 2021
Paul Backus
Jan 29, 2021
Walter Bright
Jan 29, 2021
SealabJaster
Feb 03, 2021
Q. Schroll
Feb 03, 2021
Adam D. Ruppe
Feb 03, 2021
Q. Schroll
Feb 03, 2021
Daniel N
Feb 03, 2021
Adam D. Ruppe
January 27, 2021
This is the feedback thread for the second round of Community Review of DIP 1036, "String Interpolation Tuple Literals".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

That document also provides guidelines on contributing feedback to a DIP review. Please read it before posting here. If you would like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/uhueqnulcsskznsyuhwx@forum.dlang.org
==================================

You can find DIP 1036 here:

https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

The review period will end at 11:59 PM ET on February 10, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

At the end of this review round, the DIP will be moved into the Post-Community Round 2 state. Significant revisions resulting from this review round may cause the DIP manager to require another round of Community Review, otherwise the DIP will be queued for the Final Review.

==================================
Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial post, with only two exceptions:

    - Any commenter may reply to their own posts to retract feedback contained in the original post

    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case)

* Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.

* Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in the documentation linked above will receive much gratitude). Information irrelevant to the DIP or which is not provided in service of clarifying the feedback is unwelcome.
January 27, 2021
On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
> [..]

The sentence:

> A string interpolation tuple literal, as defined below, allows one to interleave non-string data inside a string literal.

Is repeated twice in this section:

https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md#description

January 27, 2021
On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
> [snip]

Typo in the second sentence

The DIP does not account for operator overloading on strings. A DIP author that the specific example given was not possible to support, but it can work with custom types.
January 27, 2021
On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
> [snip]

More typos ("which" should be "that" in all)


Functions which accept an appropriate string type will work with string interpolation literals due to the rewrite by the compiler to the idup call.

The second use case is for functions which can process the data without needing a string translation.

However, functions which accept interp literals will work in BetterC as long as the interp template is available.

The interpolated string struct should contain its own arguments; the proposed approach of rewriting to <interplationSpec>, arg1, arg2 is confusing and prohibits implementing functions which accept two interpolated string arguments.
January 27, 2021
On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review of DIP 1036, "String Interpolation Tuple Literals".
>
> [...]

I thought "the library" was confusing. I guess Phobos is what's meant? How would that work without an import? Shouldn't it be "the runtime" instead?

The DIP says "// auto variables cannot be assigned to a interpolation sequence" but earlier on there's this:

auto msg1 = i"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
auto msg2 = ir"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
auto msg3 = i`Hello, ${name}, this is your ${visits}${post(visits)} time visiting`;
auto msg3 = q{Hello, ${name}, this is your ${visits}${post(visits)} time visiting};

I'm guessing msg3 was supposed to be `iq{...}`?
January 27, 2021
On 1/27/21 7:09 AM, Atila Neves wrote:
> On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review of DIP 1036, "String Interpolation Tuple Literals".
>>
>> [...]
> 
> I thought "the library" was confusing. I guess Phobos is what's meant? How would that work without an import? Shouldn't it be "the runtime" instead?

Yes, it's meant to be the piece of the language that lives in the library. I meant the runtime. Will change.

> The DIP says "// auto variables cannot be assigned to a interpolation sequence" but earlier on there's this:
> 
> auto msg1 = i"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
> auto msg2 = ir"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
> auto msg3 = i`Hello, ${name}, this is your ${visits}${post(visits)} time visiting`;
> auto msg3 = q{Hello, ${name}, this is your ${visits}${post(visits)} time visiting};

I can see how the statement is awkward. I'm trying to convey that the *direct translation* of the interpolation tuple literal to interleaving InterpolationLiterals and expressions cannot be assigned to an auto variable, therefore the rewrite to idup is used.

> 
> I'm guessing msg3 was supposed to be `iq{...}`?

Yes, it should be that. Will correct.

-Steve
January 27, 2021
On 1/27/21 6:43 AM, jmh530 wrote:
> On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
>> [snip]
> 
> More typos ("which" should be "that" in all)
> 
> 
> Functions which accept an appropriate string type will work with string interpolation literals due to the rewrite by the compiler to the idup call.
> 
> The second use case is for functions which can process the data without needing a string translation.
> 
> However, functions which accept interp literals will work in BetterC as long as the interp template is available.
> 
> The interpolated string struct should contain its own arguments; the proposed approach of rewriting to <interplationSpec>, arg1, arg2 is confusing and prohibits implementing functions which accept two interpolated string arguments.

Thanks. As I said, grammar is not my strong suit :P

-Steve
January 27, 2021
On 1/27/21 6:33 AM, jmh530 wrote:
> On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
>> [snip]
> 
> Typo in the second sentence
> 
> The DIP does not account for operator overloading on strings. A DIP author that the specific example given was not possible to support, but it can work with custom types.

You had me confused for a while, I didn't remember writing anything like that. But it's part of the review piece I didn't touch that Mike added after the first round. Should say "A DIP author *replied* that..."

-Steve
January 27, 2021
On 1/27/21 6:25 AM, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
>> [..]
> 
> The sentence:
> 
>> A string interpolation tuple literal, as defined below, allows one to interleave non-string data inside a string literal.
> 
> Is repeated twice in this section:
> 
> https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md#description 
> 
> 

Thanks, will fix.

-Steve
January 27, 2021
On 1/27/2021 4:09 AM, Atila Neves wrote:
> auto msg1 = i"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
> auto msg2 = ir"Hello, ${name}, this is your ${visits}${post(visits)} time visiting";
> auto msg3 = i`Hello, ${name}, this is your ${visits}${post(visits)} time visiting`;
> auto msg3 = q{Hello, ${name}, this is your ${visits}${post(visits)} time visiting};
> 
> I'm guessing msg3 was supposed to be `iq{...}`?

And shouldn't it be msg4?
« First   ‹ Prev
1 2 3