Yet another proposal of a templated string design

[Brian Goetz]

> The other thing to remark is that the current syntax, something like Format."name: \(name) age: \(age)" omits the method name, so there is need for a convention for the compiler to linked a templated string call to an actual method definition in a similar way the name "value" is used when declaring an annotation without mentioning a method name.

If what you're saying is you want a convention for inferring a magic 
method name when a type is presented, absolutely not.  That's the road 
serialization took, and we're not taking that road again.

The path to get from types to behavior is type classes.  I don't want to 
dive into the details of type classes now, but we *can* eventually get 
to where you want, in a more disciplined way, once we have type 
classes.  In the meantime, the thing to the left side of the dot is a 
receiver object.

> I think we can group those two constraints by using that a method with a special name, i will use the hyphenated name "template-policy" in the rest of the document, obviously it can be any name. Using an hyphenated name has the advantage to be clear at definition site that the method is special and acts as a kind of spread operator.
>
> So i propose that
>    Format."name: \(name) age: \(age)"

I think using type names on the LHS is a distraction, though, because 
its a weaker feature than having an object, because objects have state.  
Take the SQL example.  A Connection could be (or have) a policy object 
that does quote escaping _according to DB-specific rules_, while still 
letting users interact through a Connection (rather than a 
FooBaseConnection.)  We don't want to give that up.

> is semantically equivalent to
>    Format.template-policy(new TemplatedString("name: \uFFFC age: \uFFFC", ...), name, age).result()

Where we are now is quite close:

     receiver."Hi \{name}"

is basically equivalent to

     receiver.applyTemplatePolicy("Hi \uFFFc", name)

except that we group together the string and the parameters in a single 
object.  This has both implementation and API design benefits; the 
template policy deals in the same TemplatedString type that you'd get if 
you didn't specify a policy.

I'm still fuzzy, though, on what problem you're trying to solve. Could 
we uplevel a bit?