October 30, 2023

On Monday, 30 October 2023 at 14:03:19 UTC, Dejan Lekic wrote:

>

On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

>

the problem only exist if we call them interpolated strings. just don't to that, it will avoid endless confusion. call them interpolation tuples in the language. or whatever. just avoid calling them string at all costs.

I had the same thought last week when we discussed this on IRC. First I thought istring would be a good name, but then one can see "string" and think of it as some some kind of string, and after some time I started calling it struple . :)

I kinda like it 😅

At least then you know it's not a string

October 30, 2023

On Monday, 30 October 2023 at 14:50:42 UTC, IGotD- wrote:

>

On Monday, 30 October 2023 at 13:25:17 UTC, duckchess wrote:

>

the problem only exist if we call them interpolated strings. just don't to that, it will avoid endless confusion. call them interpolation tuples in the language. or whatever. just avoid calling them string at all costs.

They are likely to be some other type under the hood in other languages as well, yet they called interpolated strings. Now, I suggest that go to the forums of all the languages that has interpolated strings and instruct them to stop using that term.

but they act or convert to string. which has it's own set of problems.
so either D gets 'string interpolation' that acts like a string too,
or D doesn't get 'string interpolation' but a completely different feature 'interpolation tuples' or however you wanna call it, that doesn't suggest to the user that the result is a string. you can still explicitly convert the result to a string in case you need that.
it's about not confusing the users.

and no, there's no need for other languages to change, as they have string interpolation. they don't have what the proposals for D are.

October 30, 2023

On Monday, 30 October 2023 at 15:19:01 UTC, duckchess wrote:

>

and no, there's no need for other languages to change, as they have string interpolation. they don't have what the proposals for D are.

It's more accurate to say that is that the only proposals that will get serious consideration are the ones that redefine the term "string interpolation". Certainly many around here have proposed that we have string interpolation in the usual sense of the term.

October 30, 2023
On 30/10/23 13:54, IGotD- wrote:
> Nor having any form of implicit conversions in the language is a limitation.

Oh, but we do: it's called "alias this".

It would be totally possible to lower the interpolation to a struct with an `alias this` that points to a default `toString` method that would do basic concatenation.

If you think it will help you secure your code, you can have your function **only** accept the lowered struct. Otherwise, you can have a string overload in addition to / instead of that.

If you don't care where your string parameter comes from, you just act as usual, keep using strings, and let the users construct them however they prefer.

Now, the usual argument against this is that it ties the "low level" compiler to a "high level" feature like string formatting (for floats, for instance).

I understand the concern. However, most of the code is already there used in `pragma(msg, ...)` and in `static assert`, so at most it would need to add a call to `toString` (if present) for aggregated types.
October 30, 2023
On Monday, 30 October 2023 at 16:43:14 UTC, Arafel wrote:
>
> Oh, but we do: it's called "alias this".
>
> It would be totally possible to lower the interpolation to a struct with an `alias this` that points to a default `toString` method that would do basic concatenation.
>
> If you think it will help you secure your code, you can have your function **only** accept the lowered struct. Otherwise, you can have a string overload in addition to / instead of that.
>
> If you don't care where your string parameter comes from, you just act as usual, keep using strings, and let the users construct them however they prefer.
>
> Now, the usual argument against this is that it ties the "low level" compiler to a "high level" feature like string formatting (for floats, for instance).
>
> I understand the concern. However, most of the code is already there used in `pragma(msg, ...)` and in `static assert`, so at most it would need to add a call to `toString` (if present) for aggregated types.

Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward. In 99% of the cases, you don't care what string interpolation is underneath and just want a string or parameter from it. The string interpolation implementation can even change over time.

October 30, 2023
On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:
> Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward.

This considered in my original proposal, 4 1/2 years ago:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal
October 30, 2023
On 30/10/23 18:37, Adam D Ruppe wrote:
> On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:
>> Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward.
> 
> This considered in my original proposal, 4 1/2 years ago:
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal

Yes, I think I read it at the time, and it probably has unconsciously shaped my ideas, as have DIP1036 and YAIDIP (these two consciously).

Anyway, I went ahead and implemented a proof of concept, using mixins:

https://gist.github.com/erkrali/d48ed754b68a26e326b61aad78d43ab7

There's no documentation, but the code and unit tests should be quite clear. In short:

```d
foo (string s) { }
formatedFoo(IS)(IS is) if (isInterpolatedString!IS) {
	// Advanced formatting here
}

auto message = mixin(i!`Hello, $(name). Your balance is $({%f1.3}balance).`);
foo(message); // Works
formatedFoo(message): // Also works
```

The formatting part is optional and ignored in the default `toString` implementation, but still made available for libraries. The original strings representing the interpolated expressions are also made available.

Pros:

* Intrinsic cast to string.
* Can get a tuple to be used in `text` (shorthand: `mixin(it!"Hello, $(name)");`.
* In the struct you get all the existing information: The "static" text, the format string, the original symbol, and the value to interpolate.
* Can do overloads that unlock more advanced processing.
* Functions can choose whether to support only the advanced processing.
* It should be possible to use in -betterC as long as `toString` is not called, i.e. as long as only the `struct` or the `tuple` are used.

Cons:

* Well, it's a mixin. But that's just to show how it could look like.
* It's tied to `std.conv : to` for the default string conversion.
* The parsing probably stinks, has bugs, and is inefficient as hell. It could also eat your kittens. I'd assume that a "proper" implementation would be much better, but I don't have that much experience (if any at all) in this area.

So, all in all, it's just a proof-of-concept to show that it can really be done, and it's not just theory.
October 30, 2023

On Monday, 30 October 2023 at 15:53:26 UTC, bachmeier wrote:

>

On Monday, 30 October 2023 at 15:19:01 UTC, duckchess wrote:

>

and no, there's no need for other languages to change, as they have string interpolation. they don't have what the proposals for D are.

It's more accurate to say that is that the only proposals that will get serious consideration are the ones that redefine the term "string interpolation". Certainly many around here have proposed that we have string interpolation in the usual sense of the term.

you are not wrong. but at the same time there's good reason for it too.
the problem i have with built in string interpolation is, it's unflexible. that's why i'd rather see macros implemented in the language, but there's even more people against that, including walter.
but there's no way to have all options at once.

built in string interpolation:

  • simple syntax for strings.
  • unflexible for more than basic use cases.
    macros:
  • super flexible.
  • has the problem macros have, like capturing everything.
    adams proposal:
  • almost every use case is covered.
  • you can get an interpolated string with something like s!i"".
  • not what a normal user might expect, and slighly more verbose.
    Walters DIP:
  • no flexible
  • super dangerous to use

that's why i wouldn't even use i"" as syntax, but t"" to make it extra clear that it'S not string interpolation like in other languages.

November 01, 2023

On Saturday, 21 October 2023 at 18:14:55 UTC, Patrick Schluter wrote:

>

[...]
By the very nature of what interpolated strings are it is not possible to treat them as strings.

True. BTW: How can interpolations be wrapped? Consider the follwing code fragment

    auto query = i"select a from b where c = ${d}";

occurring in the same code unit as

    auto path = i"${basepath}/${configdir1}/${filename}";

How can one selectively wrap only those interpolations which concatenate path components but leave the sql queries untouched? If one used buildPath [1] from the very start this would be a non-problem.

[1] https://forum.dlang.org/post/jctprfyaolylrxwoymjm@forum.dlang.org

November 01, 2023

On Wednesday, 1 November 2023 at 21:24:44 UTC, kdevel wrote:

>

How can one selectively wrap only those interpolations which concatenate path components but leave the sql queries untouched?

You buildPath(path) and db.query(query)...

the intermediate variables still contain the unprocessed sequence suitable for passing to a function that knows how to use it.

See: https://github.com/dlang/dmd/pull/15715#issuecomment-1781745762

for details (and as i say there, you can ask the compiler! I have a full implementation with many runnable examples all right there)

4 5 6 7 8 9 10 11 12 13 14
Next ›   Last »