On Tuesday, 14 December 2021 at 13:40:02 UTC, deadalnix wrote:

Learn from each other and copy from each other.

On Thursday, 9 December 2021 at 21:06:11 UTC, WebFreak001 wrote:

To a give another POV, from a polyglot background, I'd say there is a statement in the YAIDIP which is incorrect and somewhat skews the rest of the argument:

The simplest use case of interpolated strings, and the most likely to be encountered in practice, is as argument to functions such as writeln, text, writefln, or format:

Surely the simplest use case, and most likely to be encountered, is simply to build a well formatted string from a blend of string literals and local variables:

int x = 42;
auto s = i"Let's interpolate $x!"

where s would be of string type.

I use interpolated strings in numerous languages and I do so to present a clear expression to the reading developer of the intended format of the final string, and to keep the code tidy. In fact, I code like above specifically to avoid passing messy expressions as arguments to a following function call.

I can see the power and attraction of the proposed design, but it has to be weighed against a syntax that satisfies the principle of least astonishment, as also identified in the same DIP.

I'm also thinking that if tuples were more fully integrated and rationalised in the language then the benefits offered by this DIP regarding passing argument lists to string handling functions could be achieved in some other way using syntactically convenient unpacking of tuples into argument lists, but it's been a long time now since I used D in anger so if this part of my argument is just noise then... ignore it :-)

On 12/14/21 6:15 AM, WebFreak001 wrote:

pramga(msg) and mixin do not need implementations of std.conv.text.

pragma(msg, "x = ", x); already works, just need it to ignore the header.

mixin("int y = ", x + 5, ";") already works, just need it to ignore the header.

assert would need some implementation of runtime output. But it's already in the library with -checkaction=context. It just needs to be exposed.

auto text(istring...)(istring s) if (isIString!istring)
{
     return text(s[1 .. $]); // removes special __header, just concatenate rest
}

The DIP is designed specifically to work with text as-is. You don't need a special overload (because the header has a toString that returns ""). This was inherited from our DIP.

As for the specialized call syntax, I don't think we need it.

As for implementing some text-like thing in druntime, we already have some of it, I think it would be reasonable to include something in object.d that does a straightforward conversion when you don't want to use std.format. The only complex one is floating point. This all can be done AFTER the DIP is accepted anyway.

-Steve

On Tuesday, 14 December 2021 at 14:01:56 UTC, rikki cattermole wrote:

what do you mean with this? Memory management isn't part of the language or the proposal here (you need to use std.conv : text) and the syntax you propose here is the exact syntax proposed in the post. I don't quite get where you disagree or why you are against it from this paragraph at least.

auto data = dbcon.sql`SELECT * FROM table where field = "%value$arg"`;

this is the same as JS template literal syntax - it's another way of calling a function. Given how different it looks from regular function calls, I don't think you would be very confused. The compiler would also tell you that you are trying to pass a string to a function that checks for an istring.

Just like currently a.ufcsFun(b) works but &a.ufcsFun to take its address doesn't, even though a.memberFun(b) works and &a.memberFun takes its address - I don't think anyone is confused about it, or at least it's easy to learn why the UFCS one doesn't work, just as it will with this proposal.

I was thinking about this as well - it would work but would run at runtime. I'm not a fan of using it just for static data and think hexString!"..." is better for that.

On Tuesday, 14 December 2021 at 15:58:21 UTC, WebFreak001 wrote:

Then why isn't
text!i"..."
ok? Why do we need multiple
i"..."
f"..."
?

On Tuesday, 14 December 2021 at 16:04:58 UTC, Daniel N wrote:

string name = readln();
auto greeting = text!i"hello $name!";

expands to

string name = readln();
auto greeting = text!(__header!..., "hello ", name, "!");

that wouldn't work because name is a runtime variable and you are trying to use it as a template parameter here.

You would need to do text(i!"hello $name!") or i"hello $name!".text for the YAIDIP to work

or as this post suggested a new calling syntax that extends to that: text"hello $name!"

On Tuesday, 14 December 2021 at 12:29:57 UTC, rumbu wrote:

static mostly comes from C++.
The only one of those D added that isn't natural and consistent is enum for manifest constant. I grant you some leeway for the unary is type check, but it still seems a natural extension from the binary form. (It is easy to read and understand).

If you compare the spec for the subset of D which C++ can implement, I think you will find it is more complex than the spec for D. References and lambdas for example.

When designing a language, minimizing the set of keywords is not necessarily a good goal, the opposite is often true. You want code to look obvious. There are often tricks to reuse keywords, I'm glad D generally doesn't do that.

On Tuesday, 14 December 2021 at 16:15:28 UTC, WebFreak001 wrote:

string name = readln();
auto greeting = text!(__header!..., "hello ", name, "!");

I assumed it works with alias/variadic params...?

import std;

int sum(Vs...)()
{
    int sum = 0;

    foreach(v ; Vs)
        sum += v;

    return sum;
}

void main()
{
    int a = to!int(readln());
    sum!a.writeln;
}

On Tuesday, 14 December 2021 at 20:07:43 UTC, Daniel N wrote:

string name = readln();
auto greeting = text!(__header!..., "hello ", name, "!");

import std;

int sum(Vs...)()
{
    int sum = 0;

    foreach(v ; Vs)
        sum += v;

    return sum;
}

void main()
{
    int a = to!int(readln());
    sum!a.writeln;
}

It works for variables, but not arbitrary expressions. For example, if you wrote

    sum!(a, a+1).writeln;

...then you would get an error:

Error: variable `a` cannot be read at compile time