June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Monday, 18 June 2012 at 15:36:23 UTC, deadalnix wrote:
> Le 18/06/2012 17:28, Mehrdad a écrit :
>> On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
>>> On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
>>>>> So (**IMHO**) if that's really the case, we should really spend some
>>>>> time fixing the /design/ of const before the implementation...
>>>>
>>>> This is mostly about the design of object initialisation.
>>>>
>>>>> good idea or no?
>>>>
>>>> Certainly.
>>>
>>>
>>> My initial instinct would be to require a "const constructor" in order
>>> for an object to be const-able, but I'm not sure if that would work
>>> correctly or not..
>>
>> Come to think of it, that would play REALLY nicely with 'scope' -- a
>> reference to a non-const object can be escaped from a 'const
>> constructor' if and only if the reference is scope!
>>
>> Bingo! Does that work??
>
> Indeed, this should be scope for ctor (avoid partially initialized object in 3rd party code) /dtor (avoid resurrection, which is a real pain for any GC, and a very good way to ends up with alive object in invalid state).
note: "for a CONST ctor", not just any ctor
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 06/18/2012 05:28 PM, Mehrdad wrote:
> On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
>> On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
>>>> So (**IMHO**) if that's really the case, we should really spend some
>>>> time fixing the /design/ of const before the implementation...
>>>
>>> This is mostly about the design of object initialisation.
>>>
>>>> good idea or no?
>>>
>>> Certainly.
>>
>>
>> My initial instinct would be to require a "const constructor" in order
>> for an object to be const-able, but I'm not sure if that would work
>> correctly or not..
>
> Come to think of it, that would play REALLY nicely with 'scope' -- a
> reference to a non-const object can be escaped from a 'const
> constructor' if and only if the reference is scope!
>
> Bingo! Does that work??
Yes, but it requires proper enforcement of 'scope'.
- which is undecidable/must be done conservatively
- code would have to become 'scope correct'
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Le 18/06/2012 17:50, Timon Gehr a écrit :
> On 06/18/2012 05:28 PM, Mehrdad wrote:
>> On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
>>> On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
>>>>> So (**IMHO**) if that's really the case, we should really spend some
>>>>> time fixing the /design/ of const before the implementation...
>>>>
>>>> This is mostly about the design of object initialisation.
>>>>
>>>>> good idea or no?
>>>>
>>>> Certainly.
>>>
>>>
>>> My initial instinct would be to require a "const constructor" in order
>>> for an object to be const-able, but I'm not sure if that would work
>>> correctly or not..
>>
>> Come to think of it, that would play REALLY nicely with 'scope' -- a
>> reference to a non-const object can be escaped from a 'const
>> constructor' if and only if the reference is scope!
>>
>> Bingo! Does that work??
>
> Yes, but it requires proper enforcement of 'scope'.
>
> - which is undecidable/must be done conservatively
> - code would have to become 'scope correct'
>
Come on, what can't we infers qualifiers ?
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 06/18/2012 05:12 PM, deadalnix wrote: > Le 18/06/2012 16:51, Andrei Alexandrescu a écrit : >> Mehrdad posted a code sample and you replied to it with what I could >> only assume was an explanation of the code's behavior. I hope you'd >> agree it was a reasonable assumption, whether or not it was correct. >> >> The problem at work here is that "this" is typed incorrectly during the >> construction of a qualified object. It should go progressively from a >> "raw" to a "cooked" state, and cannot be passed to any function while >> raw. >> >>> I've however made other posts to explain why >>> transitivity is broken when it comes to delegate. >> >> I looked at your posts through June and couldn't find such, so a couple >> of links would be great. Of course, bug reports would be even better! >> > > I'm not sure you are talking about the proposal or the transitivity > issue here. I'll explain the proposal below, for the explaination of why > the transitivity is broken, see : > http://forum.dlang.org/thread/ywispsasaylqscyuayae@forum.dlang.org?page=2#post-jrn7sv:24jjj:241:40digitalmars.com > > > > To explain my proposal, I have to make several thing clear first. You > have here 2 things to qualify : the delegate itself, and the hidden > parameter. As type qualifier are transitive in D, qualify the delegate > also transitively qualify the hidden parameter. > > The proposal was to use postfix qualifier notation to qualify the hidden > parameter, and qualifier between return type and delegate keyword to > qualify the delegate itself. Why would the second part of the proposal be necessary? > My original proposal stated that the type > qualifier before the return type qualify the return type, but this is > another topic. > > To make is clearer, some examples : > > void delegate() const; // A mutable delegate that use const frame > pointer (all variable accessed throw the frame pointer are made const). > void const delegate(); // A const delegate that use a const frame > pointer (transitivity). > void const delegate() immutable; // A const delegate that use an > immutable frame pointer (delegate can only access immutable data from > the frame pointer). > void immutable delegate() const; // Error, immutable data cannot refers > to const data. > > Note that the implicit cast goes the other way around than usual. void > delegate() const can be safely casted to void delegate(), but not the > other way around, as you are allowed to not mutate mutable data, but not > the other way around. Comments: 1. struct S{ int x; void foo()pure{x++;} // ok } void main(){ int x; void foo()pure{x++;} // currently an error } The second part should be allowed. It is qualifying foo as 'immutable' which should fail. 2. int y; struct S{ int x; void foo()immutable{y++;} // ok } void main(){ void foo()immutable{y++;} // should be allowed } The problem is the unfortunate annotation overhead. It would be better to have 'nostatic' as the keyword for the current 'pure' and 'pure' as a shortcut for 'immutable nostatic'. This would also silence the 'pure is a misnomer' crowd. |
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Le 18/06/2012 18:04, Timon Gehr a écrit : >> To explain my proposal, I have to make several thing clear first. You >> have here 2 things to qualify : the delegate itself, and the hidden >> parameter. As type qualifier are transitive in D, qualify the delegate >> also transitively qualify the hidden parameter. >> >> The proposal was to use postfix qualifier notation to qualify the hidden >> parameter, and qualifier between return type and delegate keyword to >> qualify the delegate itself. > > Why would the second part of the proposal be necessary? > What do you qualify as the second part ? >> My original proposal stated that the type >> qualifier before the return type qualify the return type, but this is >> another topic. >> >> To make is clearer, some examples : >> >> void delegate() const; // A mutable delegate that use const frame >> pointer (all variable accessed throw the frame pointer are made const). >> void const delegate(); // A const delegate that use a const frame >> pointer (transitivity). >> void const delegate() immutable; // A const delegate that use an >> immutable frame pointer (delegate can only access immutable data from >> the frame pointer). >> void immutable delegate() const; // Error, immutable data cannot refers >> to const data. >> >> Note that the implicit cast goes the other way around than usual. void >> delegate() const can be safely casted to void delegate(), but not the >> other way around, as you are allowed to not mutate mutable data, but not >> the other way around. > > Comments: > > 1. > > struct S{ > int x; > void foo()pure{x++;} // ok > } > > void main(){ > int x; > void foo()pure{x++;} // currently an error > } > > The second part should be allowed. It is qualifying foo as 'immutable' > which should fail. > Yes. > 2. > > int y; > struct S{ > int x; > void foo()immutable{y++;} // ok > } > > void main(){ > void foo()immutable{y++;} // should be allowed > } > > The problem is the unfortunate annotation overhead. And yes. This is another topic, but I think the way to go is inference. > It would be better to have 'nostatic' as the keyword for the > current 'pure' and 'pure' as a shortcut for 'immutable nostatic'. > > This would also silence the 'pure is a misnomer' crowd. > I don't really have an opinion on that subject. I understand the keywork choice can be confusing, but the overall design is really nice. |
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 06/18/2012 06:12 PM, deadalnix wrote:
> Le 18/06/2012 18:04, Timon Gehr a écrit :
>> It would be better to have 'nostatic' as the keyword for the
>> current 'pure' and 'pure' as a shortcut for 'immutable nostatic'.
>>
>> This would also silence the 'pure is a misnomer' crowd.
>>
>
> I don't really have an opinion on that subject. I understand the keywork
> choice can be confusing, but the overall design is really nice.
I agree. Some of the keywords are poorly chosen, but this does not have
any actual _practical_ implications for coding. Changing them, however,
does.
It is just frustrating to always be stopped mid-sentence when
explaining the design to someone unfamiliar with it, or even have them
lose interest because they think to have found a 'problem' with it.
There is also a group of one or two guys who cannot mention 'pure'
without also mentioning that they disagree with the keyword choice.
Interestingly, few oppose to 'const'. This is probably because C++ has
paved the way for it.
TL;DR: poorly chosen keywords create needless communication overhead
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Monday, 18 June 2012 at 16:23:39 UTC, Timon Gehr wrote:
> I agree. Some of the keywords are poorly chosen, but this does not have any actual _practical_ implications for coding. Changing them, however, does.
Not sure if this was intended to be referring to my post or not, but just to clarify:
The real problem is _not_ the fact that there is a technical issue with const/pure/immutable/whatever.
Like you said, that might not have any practical consequences.
The problem is that when the compiler _uses_ const/pure/immutable to make decisions regarding optimizations.
When that's the case, then IMHO they **MUST** be foolproof, no matter how rare/common they are (assuming no casts and such, to subvert the system).
Otherwise the compiler generates wrong binaries for correct code.
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 6/18/12 10:15 AM, Mehrdad wrote:
> So (**IMHO**) if that's really the case, we should really spend some
> time fixing the /design/ of const before the implementation... good idea
> or no?
It's the implementation (not design) of constructors typechecking that's the problem.
Andrei
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 6/18/12 10:24 AM, Mehrdad wrote:
> On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
>>> So (**IMHO**) if that's really the case, we should really spend some
>>> time fixing the /design/ of const before the implementation...
>>
>> This is mostly about the design of object initialisation.
>>
>>> good idea or no?
>>
>> Certainly.
>
>
> My initial instinct would be to require a "const constructor" in order
> for an object to be const-able, but I'm not sure if that would work
> correctly or not..
The constructor of a const or immutable object progressively evolves the object from a raw state to a fixed, constructed state. During the process the object has not discernable type. This is what needs to be fixed.
Andrei
|
June 18, 2012 Re: How to break const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 06/18/2012 06:30 PM, Mehrdad wrote: > On Monday, 18 June 2012 at 16:23:39 UTC, Timon Gehr wrote: >> I agree. Some of the keywords are poorly chosen, but this does not >> have any actual _practical_ implications for coding. Changing them, >> however, does. > > > Not sure if this was intended to be referring to my post or not, but > just to clarify: > It was not. ;) > > The real problem is _not_ the fact that there is a technical issue with > const/pure/immutable/whatever. > Like you said, that might not have any practical consequences. > > > The problem is that when the compiler _uses_ const/pure/immutable to > make decisions regarding optimizations. > It is important that the type system is sound. > When that's the case, then IMHO they **MUST** be foolproof, no matter > how rare/common they are (assuming no casts and such, to subvert the > system). > This must be the case even if the compiler does not optimize. > > Otherwise the compiler generates wrong binaries for correct code. Then the compiler is wrong. |
Copyright © 1999-2021 by the D Language Foundation