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

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'

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 ?

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.

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.

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

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.

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

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

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.