Suffix-based literal syntax

[Reiner Pope]

Bill Baxter wrote:
> Its a neat idea.  I wonder if the proposed transformation is the right 
> way though.
> 
>>> I propose that, for number and string literals (which already sport 
>>> suffixes at the moment) if a suffix is found not from the language, 
>>> it be rewritten as an opSuffix call, so
>>>         5km
>>>     turns into
>>>         opSuff_km(5)
>>>
> 
> Maybe that should be
> 
>    km.opSuff(5)
> 
> 
> --bb
I'm not convinced. The reason is that I would expect suffixes to be only 
a few letters (like km) yet the type name would normally be much longer.

I know that the rest of the overloaded operators must be defined as 
member functions of one of the types, but that doesn't really fit with 
the suffixes, given that they "operate" on the built-in types which 
already have literals.

I envisage a usage something like this:

struct LengthKM { ... }
alias LengthKM.opCall opSuff_km;
// Of course this would actually be auto generated by a template, but 
still...

class String { ... }
alias String.this opSuff_s; // does this alias actually work? It should.

With a String class, for instance, there's not much point in 'String' 
being the suffix -- I hardly think

     "abc"String

is better than

     String("abc")


My initial thought was also a transformation like:

     opSuff!("km")(5)

However, I think the main advantage that a free function has is that it 
can be renamed on importing and it separates the suffix name from the 
type name; my example from my original post is how I would actually 
expect suffixes to be used:

import foo.string: opSuff_fs = opSuff_s;
import bar.string: opSuff_bs = opSuff_s;

...
auto a = "abc"fs; // a is a foo string
auto b = "abc"bs; // b is a bar string

   -- Reiner