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

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

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

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

I always wondered why toString() wasn't just to!string() in the first place, short of UFCS not being implemented for all types.

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

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.

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

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

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