Infer function template parameters

[Jonathan M Davis]

On Monday, September 24, 2012 10:37:04 Jonas Drewsen wrote:
> On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas
> 
> wrote:
> > On 2012-09-21, 21:29, Jonas Drewsen wrote:
> >> A mentioned in the proposal (albeit not very clear) it
> >> requires non-templated function definitions to include both
> >> type and param names. If only one name is provided in a
> >> definition is always a param name. Unfortunately this is a
> >> breaking change for some code and that does speak against the
> >> proposal.
> > 
> > Not only is it a breaking change, it breaks one of the basic
> > design
> > desiderata of D - if it's valid C it either fails to compile or
> > compiles
> > with the same behavior as in C.
> 
> I guess it is not that basic of a desiderata after all :)
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

It has been broken upon rare occasion (e.g. static arrays are value types in 
D, not reference types like in C), but it's quite rare, and removing the 
comera operator doesn't necessarily break it. In fact, just removing the comma 
operator _definitely_ doesn't break it, because it just makes more C code 
invalid. The point is that C/C++ will compile as valid D code with the same 
semantics or that it won't compile, _not_ that C/C++ will compile as valid D 
code. The whole point is to avoid silent behavioral changes when porting C/C++ 
code to D.

Now, that being said, if tuples are added to the language proper (which that 
DIP doesn't do), that may or may not make it so that C/C++ code will end up 
compiling with different semantics when ported. I'd have to study the situation 
much more closely to be sure, but I suspect that it wouldn't, precisely 
because the types involved change and C doesn't have auto in the same way that 
D does (or any kind of type inferrence at all really), so the change in type 
would cause compilation failure, thereby avoiding silent behavioral changes.

- Jonathan M Davis