Idea: limited template expansion

[Steven Schveighoffer via Digitalmars-d]

On 1/21/16 10:02 AM, David Nadlinger wrote:
> On Thursday, 21 January 2016 at 13:36:28 UTC, Steven Schveighoffer wrote:
>> On 1/20/16 6:01 PM, David Nadlinger wrote:
>>> How would the client code be simpler with a built-in language feature?
>>
>> The use case I have in mind is a parser, let's say an xml parser.
>>
>> […]
>
> I still don't see how a language feature as described in your first post
> would make this any easier than using a template for that exact purpose
> (switching between methods to call).

It may not be an "easier" thing to have the compiler do this instead of 
the user, but conceptually to me it reads better. One can write foreach 
loops as for loops also, it's not really hard. Yet foreach loops read 
and write better conceptually than a for loop. And the boilerplate is 
cut down significantly.

I'm simply trying to get rid of the boiler plate that one would need for 
such a thing. And I'm wondering if this is a unique situation for my use 
case, or if there are other use cases. If it's just for this one case, 
it's likely not worth exploring a modification to the language.

>
> If what you are trying to say is that you want the different template
> function instantiations to return incompatible types in addition to
> that, the feature from your initial post won't help you there either.
> Values can't have different types in non-template code, so you'd
> necessarily need to make the client code a template too. Streamlining
> the runtime -> compile time value dispatch process (as shown in your
> initial example) doesn't change the fact that the type of a given value
> cannot be influenced by runtime decisions.

The client code would be a template. Essentially, the compiler would 
rewrite the block as a template function and call the appropriate one. 
But the code itself would look like an inline block.

-Steve