String Interpolation

[Jonathan M Davis]

On Friday, October 27, 2023 7:20:33 AM MDT IGotD- via Digitalmars-d wrote:
> On Friday, 27 October 2023 at 12:55:35 UTC, Arafel wrote:
> > Not possible. A string in D is just another name (literally,
> > just an alias) for an array of immutable chars. So there is no
> > string class, and no constructor to speak of, other than the
> > generic array constructor.
> >
> > Technically, the best solution would probably be to return a
> > (templated) struct with an "alias this" to the already
> > interpolated string, and all other interpolation information
> > also included, so functions would be able to choose what to
> > accept.
> >
> > But "alias this" is just a way to have implicit casting, and
> > that's something (probably rightly) opposed here on principle,
> > so I don't think we'll be having it anytime soon.
>
> Why does this work?
>
> void func(string a)
> {
> ...
> }
>
> func("string literal");

Because the type of "string literal" is string  - which as Arafel correctly
points out is immutable(char)[]. No conversion is taking place here
whatsoever.

Now, the compiler does have some extra logic where it will potentially
treat a literal as other types for you. E.G. if func took wstring,
it would just treat the literal as a wstring instead of explicitly requiring
that you use "string literal"w. Similarly, you can do

ubyte i = 1; // 1 is an int
ushort[] arr = [1, 2, 42, 22]; // the array literal is int[]

Literals have a default type which you can see if you use typeof on them,
but they can be treated as a variety of types by the compiler (null and []
are really good examples of that). And that's different from implicit
conversions, because the kind of conversions that are allowed are sometimes
completly different from what you can do with actual variables (e.g. you
can't convert int[] to ubyte[] like the compiler will do with literals
without allocating an entirely different array).

Once a literal is assigned to a variable (or even simply cast to
a specific type), then you're converting a value with a fixed type, not a
literal, and the normal rules for conversion are followed.

And the compiler couldn't do the kind of stuff that it does with literals
with interpolated strings, because those aren't values that are known at
compile time. The compiler is then dealing with actual objects with a
specific type rather than a literal that can be interpreted as a variety of
types based on how it's used.

Of course, we could have implicit conversions to string from whatever the
string inteperolation generates (e.g. by having alias this on that type),
but then that opens up all of the doors that implicit conversions do, which
is particularly problematic with generic code. It also requires that the
type know how to convert itself to a string as opposed to providing a
building block for library code to generate a string from it, which would
mean putting the formatting logic in the compiler, which arguably isn't a
great idea.

- Jonathan M Davis