[dmd-beta] D 2.059 beta 3

[Jason House]

I disagree. 2.059 contains a breaking change that appears to be causing several issues. Walter believes that C code should either compile and work or be a compile error; I think we should apply the same logic to 2.059. If an operator overload was accepted as such in 2.058 but won't be in 2.059 then it must be an error. Generalization can come later.

Sent from my iPhone

On Apr 9, 2012, at 5:52 AM, Alex Rønne Petersen <xtzgzorex at gmail.com> wrote:

> I entirely agree that it would be nice if the compiler warns for all
> wrong signatures of overloaded operators. But since it currently does
> allow arbitrary signatures (and calling them as normal functions), I
> think consistency is more important. I'm all for moving to a system
> where the compiler emits warnings for these cases, but let's do it
> properly and not just for some specific operator overloads.
> 
> Regards,
> Alex
> 
> On Mon, Apr 9, 2012 at 11:33 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> On Monday, April 09, 2012 11:26:09 Alex Rønne Petersen wrote:
>>>> It doesn't matter what the programmer intended. If specific signatures are
>>>> required for these functions, then the compiler knows exactly what they
>>>> should look like, and if they don't match, then they're wrong.
>>> 
>>> It does matter. Nothing in the D language stops you from having a
>>> function called opEquals() with arbitrary parameter types that isn't
>>> intended to actually overload *the* opEquas(). Therefore, as Kenji
>>> said, the compiler can't really judge whether you actually did intend
>>> to overload opEquals() or not.
>> 
>> Do you honestly think that that's an issue? Yes, someone _could_ choose to
>> name a function opEquals without intending to invoke it as an overloaded
>> operator, but is there _any_ reason to support that? What valid reason is
>> there to do that, _especially_ when you consider that in
>> 99.9999999999999999999999999999999% of the cases, if opEquals isn't able to be
>> invoked as an overloaded operator because its signature is wrong, it's a bug,
>> and the programmer is going to want the compiler to complain about it.
>> 
>> Also, I don't think that the spec actually says that it _is_ legal to declare
>> a function with the same name as an overloaded operator without having it be
>> that overloaded operator. It _can_ happen sometimes, because the compiler
>> tends to be picky about the signature of overloaded operators and doesn't
>> necessarily give an error if they're wrong (though it does in some cases), but
>> I would have fully expected that declaring a function with the same name as an
>> overloaded operator without it overloading that operator would be illegal.
>> However, the spec is not clear no the matter, and we're left with a situation
>> where overloaded operators may or may not work, because their signatures
>> aren't quite right, and the compiler doesn't always give you proper error
>> messages about it.
>> 
>> - Jonathan M Davis
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta