• "bearophile" <bearophileHUGS lycos.com> Jan 22 2013
• "mist" <none none.none> Jan 22 2013
• "bearophile" <bearophileHUGS lycos.com> Jan 22 2013
• "mist" <none none.none> Jan 22 2013
• "bearophile" <bearophileHUGS lycos.com> Jan 22 2013
• "mist" <none none.none> Jan 22 2013

"bearophile" <bearophileHUGS lycos.com> writes:

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

"mist" <none none.none> writes:

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.

"bearophile" <bearophileHUGS lycos.com> writes:

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

"mist" <none none.none> writes:

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.

"bearophile" <bearophileHUGS lycos.com> writes:

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

"mist" <none none.none> writes:

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.