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?
