July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2012-07-12 21:26, Jonathan M Davis wrote: > The recently added attribute inferrence for overridden functions in derived > types makes it impossible to have a non-const overload of a const function. I wonder if the attribute inference can be fined tuned a bit. So it's only applied to a method that is actually overridden and not overloaded. -- /Jacob Carlborg |
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Friday, July 13, 2012 08:55:58 Jacob Carlborg wrote:
> On 2012-07-12 21:26, Jonathan M Davis wrote:
> > The recently added attribute inferrence for overridden functions in
> > derived
> > types makes it impossible to have a non-const overload of a const
> > function.
>
> I wonder if the attribute inference can be fined tuned a bit. So it's only applied to a method that is actually overridden and not overloaded.
I believe that Kenji has a pull request intended to resolve the issue (probably by doing something like that, but I don't know). We'll see what Walter has to say though.
- Jonathan M Davis
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2012-07-13 09:03, Jonathan M Davis wrote: > I believe that Kenji has a pull request intended to resolve the issue > (probably by doing something like that, but I don't know). We'll see what > Walter has to say though. This one: https://github.com/D-Programming-Language/dmd/pull/1042 ? It says "We MUST kill attribute inference with const". -- /Jacob Carlborg |
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Friday, July 13, 2012 09:10:17 Jacob Carlborg wrote:
> On 2012-07-13 09:03, Jonathan M Davis wrote:
> > I believe that Kenji has a pull request intended to resolve the issue (probably by doing something like that, but I don't know). We'll see what Walter has to say though.
>
> This one: https://github.com/D-Programming-Language/dmd/pull/1042 ? It says "We MUST kill attribute inference with const".
Probably. I'd have to go dig for the associated bug report to be 100% sure, but that certainly sounds like it.
- Jonathan M Davis
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | I always wondered why toString() wasn't just to!string() in the first place, short of UFCS not being implemented for all types. |
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to F i L | On Friday, July 13, 2012 11:02:30 F i L wrote:
> I always wondered why toString() wasn't just to!string() in the
> first place, short of UFCS not being implemented for all types.
to!string(obj) uses typeof(obj).toString for user-defined types. Even if to!string is arguably the better way to convert to a string, it still needs an implementation, and for user-defined types, that's toString. It could be argued though that we should have just used opCast(T)() if(is(T == string)) {} rather than toString. However, given the push to have a version of toString that writes to an output range or a scoped delegate rather than creating a new string, the opCast wouldn't have fit as well ultimately.
- Jonathan M Davis
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to F i L | On 13/07/12 11:02, F i L wrote:
> I always wondered why toString() wasn't just to!string() in the first
> place, short of UFCS not being implemented for all types.
>
toString() comes from the days before D had templates.
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On Fri, 13 Jul 2012 00:18:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:
> On Friday, 13 July 2012 at 03:57:21 UTC, Steven Schveighoffer wrote:
>> On Thu, 12 Jul 2012 23:51:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:
>>
>>> On Friday, 13 July 2012 at 02:19:49 UTC, Jonathan M Davis wrote:
>>>> That raises an interesting point. With these changes, what should opEquals' signature be for classes?
>>>
>>> How about inout?
>>
>> No. opEquals returns bool.
>>
>> -Steve
>
> I meant more like
>
> bool opEquals(inout Object other) inout;
inout is meant to transfer the constancy of a parameter to the constancy of the return value. During function execution, inout is treated as another flavor of const (i.e. not modifiable).
The above function is basically equivalent to:
bool opEquals(const Object other) const;
-Steve
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Fri, 13 Jul 2012 02:49:01 -0400, Jacob Carlborg <doob@me.com> wrote:
> On 2012-07-12 22:20, Steven Schveighoffer wrote:
>
>> Many (most?) classes never care about opHash, opCmp, opEquals and
>> toString. But Object defines them, incorrectly for most cases.
>>
>> These apathetic classes would not break at all. And to make the default
>> be to inherit those methods would promote their usage or reliance on them.
>>
>> Not only that, but you are almost *forced* to define them, because you
>> don't want accidental incorrect usage of them. We have lovely
>> situations where the only solution is to define a version of the method
>> that *always throws* in a statically typed language.
>>
>> It's really a terrible solution (to force the definition of them) which
>> Andrei quite correctly pointed out only existed because of the lack of
>> templates back then.
>>
>> I think this discussion is somewhat academic at this point, as Andrei
>> seems not too keen on the idea of having dual base classes.
>
> I was trying to suggest something that is mostly backwards compatible.
>
I understand. I don't think it's worth it. I'd rather opt-in to the old way than opt-out. People are lazy, they will likely avoid specifying an alternate base class.
-Steve
|
July 13, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to F i L | On Fri, 13 Jul 2012 05:02:30 -0400, F i L <witte2008@gmail.com> wrote:
> I always wondered why toString() wasn't just to!string() in the first place, short of UFCS not being implemented for all types.
toString in itself is wasteful. It allocates a string that will likely be thrown away immediately.
Experience has shown that unnecessary allocations == low performance, at least as far as D is concerned.
Yes, to!string should work, but the method for the object should use a dchar output range as a sink, instead of converting to a string. We can build to!string on top of that.
-Steve
|
Copyright © 1999-2021 by the D Language Foundation