October 25
On 10/25/23 12:54 AM, Arafel wrote:
> On 25/10/23 8:52, Walter Bright wrote:
>> There's a thunderbird extension to do it. I use it. It's called "Render Markdown Messages".
> 
> I also use it, but that's only for rendering... it stills sends the messages as plaintext, even if one uses markdown, so the markdown shows unprocessed in the web interface.
> 
> Those of us using the extension see them properly rendered, though :-)
> 
> Apparently there is a bug for thunderbird about that:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280912
> 
> 7 years and still no sign of a solution anytime soon...

There's also this bug by our Vladimir Panteleev:

https://bugzilla.mozilla.org/show_bug.cgi?id=1717221
October 25
On 25/10/23 13:29, Jonathan M Davis wrote:
> IMHO, mixins should be explicit, obvious, and greppable, and adding a separate syntax for them which tries to hide them is going to make the language worse. However a string is generated, if the programmer wants to turn it into code, they should just use mixin, and if it's ugly, it's ugly, but at least it's clear what's going on.

I agree, however the current options regarding string interpolation seem to be suboptimal:

1. Get a string interpolation that doesn't get you strings, and that needs support from the called function (or only work in specific cases, not for `foo(string bar);`. You also can't assign to string, nor use it in most libraries that don't support it explicitly.

2. Use a library solution using string mixins (quite cumbersome as a user, and probably also inefficient).

3. Introduce high level dependencies in the language itself, at least to do the formatting.

So I was just trying to brainstorm alternatives that would allow a library solution.

The biggest hurdle is accessing to the caller's scope, so far only string mixins get that. There could be perhaps a different feature that does it, i.e. a way to define a (compile time) function that get access to the caller's scope, but I'm not sure we would actually want that.
October 25

On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

>

On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe wrote:

>

On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:

>

In C# an interpolated string is just a string

This isn't true. It is an object that can convert to string (similar to D's alias toString this;)

In fact neither, it's syntactic sugar.

int count = 10;
string s = $"I drink {count} beers";

is syntactic sugar for:

int count = 10;
DefaultInterpolationHandler dh = new DefaultInterpolationHandler();
dh.AppendLiteral("I drink ");
dh.AppendFormatted(count);
dh.AppendLiteral(" beers");
string s = dh.ToStringAndClear();

From compiler point of view, Roslyn stores in AST a interpolated string as an array of expressions which get converted before IL compilation to the code above.

I wonder why we can't do this in D, using text() or format() or everything else instead of returning tuples.

Andrea

October 25

On Wednesday, 25 October 2023 at 15:05:52 UTC, Arafel wrote:

>

On 25/10/23 13:29, Jonathan M Davis wrote:

>

IMHO, mixins should be explicit, obvious, and greppable, and adding a separate syntax for them which tries to hide them is going to make the language worse. However a string is generated, if the programmer wants to turn it into code, they should just use mixin, and if it's ugly, it's ugly, but at least it's clear what's going on.

I agree, however the current options regarding string interpolation seem to be suboptimal:

  1. Get a string interpolation that doesn't get you strings, and that needs support from the called function (or only work in specific cases, not for foo(string bar);. You also can't assign to string, nor use it in most libraries that don't support it explicitly.

  2. Use a library solution using string mixins (quite cumbersome as a user, and probably also inefficient).

  3. Introduce high level dependencies in the language itself, at least to do the formatting.

So I was just trying to brainstorm alternatives that would allow a library solution.

The biggest hurdle is accessing to the caller's scope, so far only string mixins get that. There could be perhaps a different feature that does it, i.e. a way to define a (compile time) function that get access to the caller's scope, but I'm not sure we would actually want that.

Leave these library solutions aside and turn them into a language conduciveness integrated into the compiler. Do you remember there was an x ​​in D1 time?

// D1:
  writeln(x!"e697a5 e69cac e8aa9e"); // 日本語
// D2:
  auto data = hexString!"e697a5 e69cac e8aa9e";

SDB@79

October 25

On Wednesday, 25 October 2023 at 11:40:15 UTC, Jonathan M Davis wrote:

>

On Wednesday, October 25, 2023 3:55:13 AM MDT Imperatorn via Digitalmars-d wrote:

>

On Wednesday, 25 October 2023 at 07:08:06 UTC, Walter Bright

Yes, but wouldn't it be great to have the ability to do it like the other top 25 languages?

Take C# as an example (even though a bit unfair maybe), the user never have to think about imports, he happily just uses SI wherever he likes and achives a life of eternal happiness and joy. D could also provide that. Joy.

Here are the images emphasizing the joy and fulfillment brought about by successful string interpolation compared to the despair of failing to achieve it. Each image accentuates the significance of returning a string through string interpolation in bringing joy to life

On the left, a lively neighborhood with diverse residents of different genders and descents throwing a block party, dancing, and rejoicing. Screens showcase the magic of successful string interpolation. Bright lights and vivacious colors symbolize the joy of returning a string. On the right, a desolate town square with people of different genders and descents in despair, with gloomy colors and storm clouds, symbolizing the downfall from failed string interpolation.

Just look:
Joy

It continues:

Left side: a vibrant outdoor celebration with diverse students of various genders and descents, laughing, collaborating, and showcasing projects that champion successful string interpolation. Festive decorations and lively music capture the essence of joy. Right side: a gloomy library with students of different genders and descents looking frustrated, surrounded by stacks of books and screens filled with error messages, representing the struggle without proper string interpolation.

Think about it

October 25

On Wednesday, 25 October 2023 at 15:55:07 UTC, Andrea Fontana wrote:

>

On Monday, 23 October 2023 at 14:12:25 UTC, Rumbu wrote:

>

On Saturday, 21 October 2023 at 18:59:13 UTC, Adam D Ruppe wrote:

>

On Saturday, 21 October 2023 at 18:31:10 UTC, Imperatorn wrote:

>

In C# an interpolated string is just a string
I wonder why we can't do this in D, using text() or format() or everything else instead of returning tuples.

Andrea

I can answer you, because we love bikeshedding :D

Each page represents a century, and a glowing marker points to the 90th page with a note saying 'String Interpolation in D - Still in Progress'. A robot stands nearby looking puzzled.
Wait 1

Depiction of a sage on a mountaintop in a post-apocalyptic world. He holds a scroll that reads 'Prophecy: String Interpolation in D will take over 9000 years'. In the background, remnants of a lost civilization are visible.

Wait 2

October 25

On Wednesday, 25 October 2023 at 15:55:07 UTC, Andrea Fontana wrote:

>

I wonder why we can't do this in D, using text() or format() or everything else instead of returning tuples.

D can do this, but it has limitations that affect D uniquely.

D can manipulate types and aliases. Tuples are compatible with this. Wrapper objects are not.

Besides, even if we gave up on type and alias support, implicit string interpolation is still problematic.

I've written about all this many, many times in previous dips and blog posts. That's why I wish this thread was closed. It has been done to death and you should read the old reports instead of running int he same circles over and over again.

October 25

On Wednesday, 25 October 2023 at 18:22:50 UTC, Adam D Ruppe wrote:

>

I've written about all this many, many times in previous dips and blog posts. That's why I wish this thread was closed. It has been done to death and you should read the old reports instead of running int he same circles over and over again.

Send me a link about these things you wrote. I missed them. I would like to understand what's wrong with text() syntax sugar.

Andrea

October 25

On Wednesday, 25 October 2023 at 18:54:21 UTC, Andrea Fontana wrote:

>

Send me a link about these things you wrote. I missed them. I would like to understand what's wrong with text() syntax sugar.

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal

(in this one, i came out in favor of an object, but on the fence for implicit conversion to string, my position is now that the implicit conversion to string is undesirable, and this weakens the case of the object over the other alternatives)

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

(see also the linked review threads from that)

This isn't D specific, even Wikipedia has a page on it:

https://en.wikipedia.org/wiki/String_interpolation#Security_issues

And newer additions to languages try to do it right:

https://openjdk.org/jeps/430

Note:

>

String interpolation is dangerous

Unfortunately, the convenience of interpolation has a downside: It is easy to construct strings that will be interpreted by other systems but which are dangerously incorrect in those systems.

[snip ]

Can we do better?

For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.

October 25

On Wednesday, 25 October 2023 at 15:05:52 UTC, Arafel wrote:

>

On 25/10/23 13:29, Jonathan M Davis wrote:

>

IMHO, mixins should be explicit, obvious, and greppable, and adding a separate syntax for them which tries to hide them is going to make the language worse. However a string is generated, if the programmer wants to turn it into code, they should just use mixin, and if it's ugly, it's ugly, but at least it's clear what's going on.

I agree, however the current options regarding string interpolation seem to be suboptimal:

  1. Get a string interpolation that doesn't get you strings, and that needs support from the called function (or only work in specific cases, not for foo(string bar);. You also can't assign to string, nor use it in most libraries that don't support it explicitly.

  2. Use a library solution using string mixins (quite cumbersome as a user, and probably also inefficient).

  3. Introduce high level dependencies in the language itself, at least to do the formatting.

So I was just trying to brainstorm alternatives that would allow a library solution.

The biggest hurdle is accessing to the caller's scope, so far only string mixins get that. There could be perhaps a different feature that does it, i.e. a way to define a (compile time) function that get access to the caller's scope, but I'm not sure we would actually want that.

from the discussion in the chat: the things that is bad about mixins is that they allow mutations, so implicitly mixin something in can cause unexpected things to happen. i suggested const_mixin() instead that captures the scope, but only readonly.

so

template i(string s) { mixin = s; }
float foo = 42;
writeln(i!"${foo}"); //ok
writeln(i!"${foo++}"); // error, cant mutate foo. need to use explicit mixin(i!"${foo++}")

it would be a more hygienic version of the idea, but no idea if walter would accept this.