shouting versus dotting

[Benji Smith]

Andrei Alexandrescu wrote:
> Benji Smith wrote:
>> Andrei Alexandrescu wrote:
>>> b) Template at Arg and Template@(Args)
>>>
>>> This approach not only accepts the need for a contraption, it 
>>> actually leverages it by allowing you to drop the parens if you only 
>>> have one argument. That way "@" becomes a true operator, the template 
>>> instantiation operator. Note that this can be done with the current 
>>> "!" as well, except that Template!Arg does not look to me like 
>>> anything enticing.
>>
>> Interesting.
>>
>>    // If this is possible.......
>>    auto myTemplate = Template @ (1, 2, 3, uint);
>>
>>    // ......shouldn't this be possible too?
>>    auto args = (1, 2, 3, uint);
>>    auto myTemplate = Template @ args;
>>
>> All other binary operators can operate on either a literal or on an 
>> expression, and I'd expect a template instantiation operator to do the 
>> same.
>>
>> What do you think?
> 
> I think you will have a hard time (re)using parentheses and commas to 
> define literals.
> 
> Andrei

The actual syntax I used isn't important. That's not what I was talking 
about.

It was the idea that template instantiation is the result of a binary 
operator. Which, to me, implies that the operands could be either 
literals or other types of expressions. I suppose the real syntax would 
be more like this:

    auto args = Tuple @ (1, 2, 3, real);
    auto myTemplate = Template @ args;

So, if "@" is a binary operator, it has two operands: a template name 
and an argument list. But, currently, there's no way to express either 
of those constructs symbolically. Only literally.

It seems to me that, in your proposal, "@" is not really an operator. It 
might act a little bit like an operator, but since its operands can't 
exist by themselves, then they're not really operands. And "@" is not an 
operator.

It'd be cool if template instantiation really was the result of an 
operator, with all of the necessary implications regarding the operands.

Of course, I'm not actually *proposing* that implementation. I'm just 
drawing a fine line in the sand delineating what it actually means to be 
an "operator" rather than "template syntax".

--benji