Infer function template parameters

[Jonas Drewsen]

On Monday, 24 September 2012 at 10:05:49 UTC, Jonathan M Davis 
wrote:
> 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

What about:

int fun() {
     return (0, "abc")[0];
}

in the comma operator case it would return 'a' as an int.
in the tuple case it would return 0

/Jonas