On 12/14/2019 5:52 PM, Adam D. Ruppe wrote:
> On Sunday, 15 December 2019 at 01:44:18 UTC, Walter Bright wrote:
>> The extra syntax kills it
> This is true, but ONLY for the printf case. It just works in all other cases.

printf is a very important case, and it kills it for scanf and every other function that takes a format string (dmd itself has many printf-like functions).

>> with the extra import required, along with not working with #betterC.
> No need for import - this is a definition in object.d,

object.d is getting more and more bloated over time. This is not a solution to imports, and is not a good trend.


> and it will work in betterC since this is a compile-time transformation (the `asFormatString` definition is essentially just `template asFormatString(T...) { alias asFormatString = T; }`.
> 
> And my proposal also doesn't need an import to be assigned to a string whereas yours does.
> 
> string a = i""; // mine would trigger the alias toString this and just work
> 
> string a = format(i""); // must import std.format. also fails in betterC btw

betterC is for use without Phobos.

>> It's just not the default.
> Which is usable (that's why I'm not opposed to your proposal) but means it is now impossible to catch accidental misuses at compile time. They type system no longer helps you.

That's always been true with printf. Many C compilers have extensions to deal with this, but D never incorporated them (although it could).


> But what about a small compromise: what if JUST the format string was given a new type and the rest was still a tuple. The format string can implicitly convert to the same things a string literal can; it can go to `string` or to `const char*`, but then user-defined functions are also able to overload on it.
> 
> So
> 
> i"hi %test"
> 
> becomes basically
> 
> typedef string InterpolatedFormat;
> 
> type_tuple(InterpolatedFormat("hi %s"),  test)
> 
> That'd still work in printf - it just implicitly converts back to char* - and gives just enough type information hints to cover my advanced use cases too.

Adding a new basic type to the language just for this is not worth it.

With the proposal, I can explain it in one slide, which is worth a great deal.

On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
> On 12/14/2019 5:52 PM, Adam D. Ruppe wrote:
>> On Sunday, 15 December 2019 at 01:44:18 UTC, Walter Bright wrote:
>>> The extra syntax kills it
>> This is true, but ONLY for the printf case. It just works in all other cases.
>
> printf is a very important case, and it kills it for scanf and every other function that takes a format string (dmd itself has many printf-like functions).

IIRC you said dmd was just a direct translation from C and carries all that legacy debt. Is that really an example you want to be using to justify your point?

>>> It's just not the default.
>> Which is usable (that's why I'm not opposed to your proposal) but means it is now impossible to catch accidental misuses at compile time. They type system no longer helps you.
>
> That's always been true with printf. Many C compilers have extensions to deal with this, but D never incorporated them (although it could).

You don't need to add an extra feature and warnings to the compiler. There's already a type system that can be used. Also that feature isn't that simple to implement. I see all the hacks to get around it in android's kernel source. They treat the warning as an error, even with the hacks in the source code. It still gives false positives and I end up disabling it or just deleting the logs that are causing the error.

If it was important it would already have been implemented, but no one uses printf as there are better alternatives.

On Sunday, 15 December 2019 at 01:52:20 UTC, Adam D. Ruppe wrote:

> string a = i"";

This is for me the most important thing for string interpolation. A convenient string assignment.
If this is not convenient, it destroys the great feature of string interpolation.

Walter, could you please make it happen?

Kind regards
Andre

On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
>
> With the proposal, I can explain it in one slide, which is worth a great deal.


To use it people will need to understand how to use d tuples as well. This seems like optimizing for betterC? Why not optimize for the D case? Do you know how many users even use betterC?

People will write writeln(i”$var bananas”) and see it not work, and not understand why. The most basic case doesn’t work either with this proposal (assigning a what-you-intuitively-think is a string to a string).

On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
> object.d is getting more and more bloated over time. This is not a solution to imports, and is not a good trend.

A bit other topic, but this can be fixed by splitting object.d in multiple modules in same package, and auto import that package, just like how it is done in java with java.lang package.

For example, object.d could be split into several modules under d.lang package.

This will also clean existing bloatware, since we could move typeinfo, object definition and other stuff into separated modules.

Best regards,
Alexandru.

On Sunday, 15 December 2019 at 01:44:18 UTC, Walter Bright wrote:
> On 12/14/2019 6:23 AM, Adam D. Ruppe wrote:
>> On Saturday, 14 December 2019 at 09:10:47 UTC, Walter Bright wrote:
>>> I find your proposal a little confusing. By turning the string into an object, it doesn't work with printf?
>> 
>> Right, not directly. But then it is trivial to add a member of the object that transforms it into a tuple suitable for printf.
>> 
>> So the end user's code now looks like: `printf(i"foo %bar".asFormatTuple);`
>
> I was afraid that would be it. The extra syntax kills it,

I highly doubt that modern D applications use printf enough that we should cater so much for it. Anyhow, I don't see why we couldn't add an overload even for printf in druntime if the .toString or .asFormatTuple is too much syntax.

> along with the extra import required,

It's a member of the struct. No import required.

> along with not working with #betterC.

Why? I don't see an argument for this. The interpolated struct is templated, so the compiler would generate a new instance properly.
In fact, even a potential printf overload in druntime would still work with #worseD as long as its templated.

On 15/12/2019 11:33 PM, Alexandru Ermicioi wrote:
> On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
>> object.d is getting more and more bloated over time. This is not a solution to imports, and is not a good trend.
> 
> A bit other topic, but this can be fixed by splitting object.d in multiple modules in same package, and auto import that package, just like how it is done in java with java.lang package.
> 
> For example, object.d could be split into several modules under d.lang package.
> 
> This will also clean existing bloatware, since we could move typeinfo, object definition and other stuff into separated modules.
> 
> Best regards,
> Alexandru.

Yes please.

On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1027, "String Interpolation":
>
> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
>

I like this proposal.
It sounds like a no-brainer YES.

On Sunday, 15 December 2019 at 09:30:45 UTC, Andre Pany wrote:
>> string a = i"";
>
> This is for me the most important thing for string interpolation. A convenient string assignment.
> If this is not convenient, it destroys the great feature of string interpolation.
>
> Walter, could you please make it happen?
>
> Kind regards
> Andre

Careful that if that happens, then it may be another feature that can't be used without a runtime. As it stands, it is usable with snprintf @nogc and that's pretty cool in my book.

On Sunday, 15 December 2019 at 15:36:09 UTC, Guillaume Piolat wrote:
> On Sunday, 15 December 2019 at 09:30:45 UTC, Andre Pany wrote:
>>> string a = i"";
>>
>> This is for me the most important thing for string interpolation. A convenient string assignment.
>> If this is not convenient, it destroys the great feature of string interpolation.
>>
>> Walter, could you please make it happen?
>>
>> Kind regards
>> Andre
>
> Careful that if that happens, then it may be another feature that can't be used without a runtime. As it stands, it is usable with snprintf @nogc and that's pretty cool in my book.

There's no reason it can't be implicitly converted to a string. You could also easily write a @nogc wrapper if it outputs a tuple. It being usable with snprintf() means it outputs something that pretty much no other function uses. The only thing I know of that implements printf-style formatting is printf (or uses sprintf to implement it). All other use cases (the more common ones) this becomes a useless feature. Ultimately this DIP is trying to push a library specific detail (from another language) into D. That's just a bad idea.