Thread overview
Some dynamic dispatch to reduce template bloat
Jan 22, 2013
bearophile
Jan 22, 2013
mist
Jan 22, 2013
bearophile
Jan 22, 2013
mist
Jan 22, 2013
bearophile
Jan 22, 2013
mist
January 22, 2013
This "Dynamic dispatch" section of the Clay language documentation shows a way to avoid some template bloat (that is common in Clay):

https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls

Maybe it's possible to make that syntax&code shorter and lighter.

Bye,
bearophile
January 22, 2013
On Tuesday, 22 January 2013 at 11:09:05 UTC, bearophile wrote:
> This "Dynamic dispatch" section of the Clay language documentation shows a way to avoid some template bloat (that is common in Clay):
>
> https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls
>
> Maybe it's possible to make that syntax&code shorter and lighter.
>
> Bye,
> bearophile

May be I do not get it, but this can already be done in D. There is always a trade-off between template binary bloat and performance penalty of dynamic typing and suggested approach (make a templated light interface and code most function using  dynamic typing) is not that uncommon one even in C++ world.
January 22, 2013
mist:

> this can already be done in D.

Of course. But that link is a starting point to invent a possible syntax sugar.

Sometimes some sugar makes the difference from nearly never using a feature, and using it when it's useful.


> There is always a trade-off between template binary bloat and performance penalty of dynamic typing

Right. A flexible language allows you to chose case by case (with a default, when you don't care).

Bye,
bearophile
January 22, 2013
What syntax sugar do you propose? There is hardly anything in the link that can't be done with current std.variant.Algebraic at first glance. Only stuff I can think of is some convenient way to retrieve strongly typed value from Algebraic back, but that is library update, nothing to do about language syntax.
January 22, 2013
mist:

> What syntax sugar do you propose?

Maybe some tagging to denote what template arguments should be autoboxed?

The last piece of code in that page shows two saveClient() functions. Maybe only one of them is needed, and the other can be auto-generated.

Bye,
bearophile
January 22, 2013
On Tuesday, 22 January 2013 at 14:39:58 UTC, bearophile wrote:
> mist:
>
>> What syntax sugar do you propose?
>
> Maybe some tagging to denote what template arguments should be autoboxed?
>
> The last piece of code in that page shows two saveClient() functions. Maybe only one of them is needed, and the other can be auto-generated.
>
> Bye,
> bearophile

So far not convincing, do not see a lot of added value for new syntax :)
Thanks for your explanations anyway.