Le 18/02/2012 16:04, Timon Gehr a écrit :
> For them, it is certainly safe. It is questionable how large the
> effective benefit is for const, since the const qualifier would be
> inherited for the method only, but not for its parameters.
>

The const qualifier does NEVER qualify a function. This is a misconception. In what we call const function, what is const is the hhidden parameter "this", not the function.

On 02/18/2012 10:06 PM, deadalnix wrote:
> Le 18/02/2012 16:04, Timon Gehr a écrit :
>> For them, it is certainly safe. It is questionable how large the
>> effective benefit is for const, since the const qualifier would be
>> inherited for the method only, but not for its parameters.
>>
>
> The const qualifier does NEVER qualify a function. This is a
> misconception.

I don't care whether or not it is a misconception. It is how the language is defined. If you want to change this, file an enhancement request.

> In what we call const function, what is const is the
> hhidden parameter "this", not the function.

Both are const. Ask the compiler.

struct S{
    void foo()const{
        static assert(is(typeof(this)==const));
        static assert(is(typeof(foo)==const));
    }
}

In fact, the incident that the method is const is what enables contravariant overriding of mutable/immutable by const methods. (This is not supported for the explicit formal parameter types.)

This doesn't make any sense. The const-ness of *this* is the logical
and obvious reason why methods overload on const. *this* is just as
good an valid parameter as everything other ones despite the fact,
that its hidden. The signature of two functions differ between *this*
parameter has different types. There we go: sensible overloading and
const never refers to the function itself.
The fact, that it does currently is a big bug, IMO.

On Sun, Feb 19, 2012 at 1:18 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 02/18/2012 10:06 PM, deadalnix wrote:
>>
>> Le 18/02/2012 16:04, Timon Gehr a écrit :
>>>
>>> For them, it is certainly safe. It is questionable how large the effective benefit is for const, since the const qualifier would be inherited for the method only, but not for its parameters.
>>>
>>
>> The const qualifier does NEVER qualify a function. This is a misconception.
>
>
> I don't care whether or not it is a misconception. It is how the language is defined. If you want to change this, file an enhancement request.
>
>
>> In what we call const function, what is const is the hhidden parameter "this", not the function.
>
>
> Both are const. Ask the compiler.
>
> struct S{
>    void foo()const{
>        static assert(is(typeof(this)==const));
>        static assert(is(typeof(foo)==const));
>    }
> }
>
> In fact, the incident that the method is const is what enables contravariant overriding of mutable/immutable by const methods. (This is not supported for the explicit formal parameter types.)



-- 
Bye,
Gor Gyolchanyan.

On 17/02/2012 05:08, Kapps wrote:
> On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis wrote:
>> On Thursday, February 16, 2012 18:49:40 Walter Bright wrote:
>>> Given:
>>>
>>> class A { void foo() { } }
>>> class B : A { override pure void foo() { } }
>>>
>>> This works great, because B.foo is covariant with A.foo, meaning it can
>>> "tighten", or place more restrictions, on foo. But:
>>>
>>> class A { pure void foo() { } }
>>> class B : A { override void foo() { } }
>>>
>>> fails, because B.foo tries to loosen the requirements, and so is not
>>> covariant.
>>>
>>> Where this gets annoying is when the qualifiers on the base class
>>> function
>>> have to be repeated on all its overrides. I ran headlong into this when
>>> experimenting with making the member functions of class Object pure.
>>>
>>> So it occurred to me that an overriding function could *inherit* the
>>> qualifiers from the overridden function. The qualifiers of the
>>> overriding
>>> function would be the "tightest" of its explicit qualifiers and its
>>> overridden function qualifiers. It turns out that most functions are
>>> naturally pure, so this greatly eases things and eliminates annoying
>>> typing.
>>>
>>> I want do to this for @safe, pure, nothrow, and even const.
>>>
>>> I think it is semantically sound, as well. The overriding function
>>> body will
>>> be semantically checked against this tightest set of qualifiers.
>>>
>>> What do you think?
>>
>> No. Absolutely not. I hate the fact that C++ does this with virtual.
>> It makes it so that you have to constantly look at the base classes to
>> figure out what's virtual and what isn't. It harms maintenance and
>> code understandability. And now you want to do that with @safe, pure,
>> nothrow, and const? Yuck.
>>
>> I can understand wanting to save some typing, but I really think that
>> this harms code maintainability. It's the sort of thing that an IDE is
>> good for. It does stuff like generate the function signatures for you
>> or fill in the attributes that are required but are missing. I grant
>> you that many D developers don't use IDEs at this point (at least not
>> for D) and that those sort of capabilities are likely to be in their
>> infancy for the IDEs that we _do_ have, but I really think that this
>> is the sort of thing that should be left up to the IDE. Inferring
>> attribtutes like that is just going to harm code maintainibility. It's
>> bad enough that we end up with them not being marked on templates due
>> to inferrence, but we _have_ to do it that way, because the attributes
>> vary per instantiation. That is _not_ the case with class member
>> functions.
>>
>> Please, do _not_ do this.
>>
>> - Jonathan M Davis
>
> In the situation where the IDE writes it for you, said IDE will help you
> only when you write the code.
>
> In the situation where the IDE tells you what they are (through
> something like hovering over it), it will help you no matter who writes
> the code. It is also significantly easier to implement, particularly
> taking into consideration things like style, comments, etc.

Exactly. If one is worried about having to look at the base classes, it's quite easy to check that info when you are using an IDE - for example, with a hover over the overriding function which lists all the parameters and attributes, and documentation too.


-- 
Bruno Medeiros - Software Engineer

On 17/02/2012 02:49, Walter Bright wrote:
> Given:
>
> class A { void foo() { } }
> class B : A { override pure void foo() { } }
>
> This works great, because B.foo is covariant with A.foo, meaning it can
> "tighten", or place more restrictions, on foo. But:
>
> class A { pure void foo() { } }
> class B : A { override void foo() { } }
>
> fails, because B.foo tries to loosen the requirements, and so is not
> covariant.
>
> Where this gets annoying is when the qualifiers on the base class
> function have to be repeated on all its overrides. I ran headlong into
> this when experimenting with making the member functions of class Object
> pure.
>
> So it occurred to me that an overriding function could *inherit* the
> qualifiers from the overridden function. The qualifiers of the
> overriding function would be the "tightest" of its explicit qualifiers
> and its overridden function qualifiers. It turns out that most functions
> are naturally pure, so this greatly eases things and eliminates annoying
> typing.
>
> I want do to this for @safe, pure, nothrow, and even const.
>
> I think it is semantically sound, as well. The overriding function body
> will be semantically checked against this tightest set of qualifiers.
>
> What do you think?

Sounds like a good idea.
I would even add to this that it might be useful to have similar syntax that would allow to define an override method without having to specify the return type nor the parameters of the overridden method. Sometimes in class hierarchies there is a lot of redundancy when overriding methods and it could be a nice small feature to reduce that (especially for methods with lots of parameters).

class Foo {
	int num;
	
	override opEquals {
		if(cast(Foo) o is null)
			return false;
		return this.num == (cast(Foo) o).num;
	}
	
	override toString {
		return to!(string)(num);
	}
	
}

-- 
Bruno Medeiros - Software Engineer

On 2/23/2012 8:59 AM, Bruno Medeiros wrote:
> I would even add to this that it might be useful to have similar syntax that
> would allow to define an override method without having to specify the return
> type nor the parameters of the overridden method. Sometimes in class hierarchies
> there is a lot of redundancy when overriding methods and it could be a nice
> small feature to reduce that (especially for methods with lots of parameters).
>
> class Foo {
> int num;
>
> override opEquals {
> if(cast(Foo) o is null)
> return false;
> return this.num == (cast(Foo) o).num;
> }
>
> override toString {
> return to!(string)(num);
> }
>
> }


Not a bad idea, but it would be problematic if there were any overloads.

If it can be applied to const, wouldn't it be like "const by convention" that you argued against?

On Friday, 17 February 2012 at 02:49:40 UTC, Walter Bright wrote:
> Given:
>
>     class A { void foo() { } }
>     class B : A { override pure void foo() { } }
>
> This works great, because B.foo is covariant with A.foo, meaning it can "tighten", or place more restrictions, on foo. But:
>
>     class A { pure void foo() { } }
>     class B : A { override void foo() { } }
>
> fails, because B.foo tries to loosen the requirements, and so is not covariant.
>
> Where this gets annoying is when the qualifiers on the base class function have to be repeated on all its overrides. I ran headlong into this when experimenting with making the member functions of class Object pure.
>
> So it occurred to me that an overriding function could *inherit* the qualifiers from the overridden function. The qualifiers of the overriding function would be the "tightest" of its explicit qualifiers and its overridden function qualifiers. It turns out that most functions are naturally pure, so this greatly eases things and eliminates annoying typing.
>
> I want do to this for @safe, pure, nothrow, and even const.
>
> I think it is semantically sound, as well. The overriding function body will be semantically checked against this tightest set of qualifiers.
>
> What do you think?

On Thursday, 23 February 2012 at 18:32:12 UTC, Walter Bright wrote:

> Not a bad idea, but it would be problematic if there were any overloads.

It is still applicable to return types.
But i don't like the idea. If you omit arguments and return type, you force both yourself and the reader to check the base class for everything.

On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis wrote:

> No. Absolutely not. I hate the fact that C++ does this with virtual. It makes
> it so that you have to constantly look at the base classes to figure out what's
> virtual and what isn't. It harms maintenance and code understandability. And
> now you want to do that with @safe, pure, nothrow, and const? Yuck.
>
> I can understand wanting to save some typing, but I really think that this
> harms code maintainability. It's the sort of thing that an IDE is good for. It
> does stuff like generate the function signatures for you or fill in the
> attributes that are required but are missing. I grant you that many D
> developers don't use IDEs at this point (at least not for D) and that those
> sort of capabilities are likely to be in their infancy for the IDEs that we
> _do_ have, but I really think that this is the sort of thing that should be
> left up to the IDE. Inferring attribtutes like that is just going to harm code
> maintainibility. It's bad enough that we end up with them not being marked on
> templates due to inferrence, but we _have_ to do it that way, because the
> attributes vary per instantiation. That is _not_ the case with class member
> functions.
>
> Please, do _not_ do this.
>
> - Jonathan M Davis

As much as i hate the "pure const system trusted" spam, I don't think i like the idea either. If you are not using an IDE or a mouse, this would be hell. A language shouldn't be designed with such assumptions, unless you are Microsoft.

Thing is, this will make things harder not easier. (which i think is the intention here) When you overload a function, at most you copy/paste it from base class.

UTC, so wrote:
> If you are not using an IDE or a mouse, this would be hell.

lol wut? This isn't the 80's.

In all seriousness, I think you're decoupling inherently ingrained pieces: the language and it's tools. The same way you *need* syntax highlighting to distinguish structure, you *should* have other productivity tools to help you analyze data-layout. It's not like these tools don't exist in abundance on every platform. And MS has pulled some really stupid shit in its day, but it's developer tools and support do not fall under that category.