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
