• FeepingCreature (27/27) Aug 04 2019 Right now, we can write format("Hello %s", 5), or we can write
• Olivier FAURE (5/9) Aug 05 2019 I'd suggest
• FeepingCreature (13/23) Aug 05 2019 Seems extraneous. Enums are not types, fmt is not a variable.
• Nick Treleaven (9/19) Aug 10 2019 Sounds great. I think the main advantages are optimization and
• Nick Treleaven (2/3) Aug 11 2019 Where I said literal, I meant compile-time known value.

FeepingCreature <feepingcreature gmail.com> writes:

Right now, we can write format("Hello %s", 5), or we can write 
"Hello %s".format(5). This is an appealing syntax that also 
appears in other languages like Python.

To take advantage of compile-time parameter checking, we can also 
pass the format string as a template parameter: format!"Hello 
%s"(5). If I'd called with (5, 6), it would have been a compile 
error. However, there is no equivalent UFCS syntax for 
templated-formatstring format!

Forms like "Hello %s".!format(5) seem obvious, but look ugly. 
Luckily, there's an easier way.

With something like format("Hello %s", 5); the types of the 
parameters to format are translated into template type arguments; 
in other words, this is equivalent to format!int("Hello %s", 5). 
Let's call this template type inference.

Since D templates have value parameters, this suggests an 
analogous process of template value inference. How would this 
look?

void format(string fmt, T...)(fmt, T args);

In other words, we specialize format for the *value* of the 
template parameter fmt, and then let IFTI/template inference do 
the work of figuring out the appropriate template instantiation, 
exactly as before.

With this change, format!"..." would no longer be necessary at 
all; all format calls of the form format("format string", args) 
would be templated on the string's value, as they already are on 
the argument types.

Thoughts?

Olivier FAURE <couteaubleu gmail.com> writes:

On Monday, 5 August 2019 at 06:49:32 UTC, FeepingCreature wrote:
 Since D templates have value parameters, this suggests an 
 analogous process of template value inference. How would this 
 look?

 void format(string fmt, T...)(fmt, T args);

I'd suggest

     void format(enum Fmt: string, T...)(Fmt fmt, T args);

That said, does the use case of needing UFCS with a template for 
a formatting string come up *that* often?

FeepingCreature <feepingcreature gmail.com> writes:

On Monday, 5 August 2019 at 08:42:29 UTC, Olivier FAURE wrote:
 On Monday, 5 August 2019 at 06:49:32 UTC, FeepingCreature wrote:
 Since D templates have value parameters, this suggests an 
 analogous process of template value inference. How would this 
 look?

 void format(string fmt, T...)(fmt, T args);

 I'd suggest

     void format(enum Fmt: string, T...)(Fmt fmt, T args);

Seems extraneous. Enums are not types, fmt is not a variable. 
You'd basically be messing with the type system (introducing 
static single-value types, similar to the range propagation 
magic) for the sake of syntax. Besides, we already have a syntax 
for template value parameters.

 That said, does the use case of needing UFCS with a template 
 for a formatting string come up *that* often?

I mean, we're using format!"" exclusively, for typechecked 
safety. We actually have a regex that translates "foo".format() 
into format!"foo"() form. It would be nice to not have to do 
that, especially since ufcs form really is more readable. More 
than that, though, it is such a logical extension of how 
templates already work that I think it should work for that 
reason alone.

Nick Treleaven <nick geany.org> writes:

On Monday, 5 August 2019 at 06:49:32 UTC, FeepingCreature wrote:
 void format(string fmt, T...)(fmt, T args);

 In other words, we specialize format for the *value* of the 
 template parameter fmt, and then let IFTI/template inference do 
 the work of figuring out the appropriate template 
 instantiation, exactly as before.

 With this change, format!"..." would no longer be necessary at 
 all; all format calls of the form format("format string", args) 
 would be templated on the string's value, as they already are 
 on the argument types.

 Thoughts?

Sounds great. I think the main advantages are optimization and 
compile-time checking rather than UFCS.

IFTI should prefer template value parameter inference over an 
overload that takes the parameter at runtime. (The overload is 
still necessary for non-literal arguments).

Then we could call a function with compile time optimization 
without even having to be aware of a template overload that takes 
a literal value argument at compile-time instead of runtime.

Nick Treleaven <nick geany.org> writes:

On Saturday, 10 August 2019 at 17:55:14 UTC, Nick Treleaven wrote:
 (The overload is still necessary for non-literal arguments).

Where I said literal, I meant compile-time known value.