On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>  void main(string[] args)
>  {
>     auto c = new const C;
>  }
>
>  Does not compile. But if I change to const(C) it does compile. It is a bit unusual that parens make such a big difference. Thank you, Dee Girl

When it comes to parens-version versus non-parens-version, it's not really a problem if one of the two doesn't compile. It would be a bigger problem if both compile, but behave differently.

But I agree with you. "new const C" should behave like "new const(C)".

However, what you probably should have written is:

    const c = new C;

because "auto" is what you use in the absence of any other attribute. In this case, it suffices to create a new C, and then assign it to a const-thereafter variable.

Janice Caron Wrote:

> On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> >  void main(string[] args)
> >  {
> >     auto c = new const C;
> >  }
> >
> >  Does not compile. But if I change to const(C) it does compile. It is a bit unusual that parens make such a big difference. Thank you, Dee Girl
> 
> When it comes to parens-version versus non-parens-version, it's not really a problem if one of the two doesn't compile. It would be a bigger problem if both compile, but behave differently.
> 
> But I agree with you. "new const C" should behave like "new const(C)".
> 
> However, what you probably should have written is:
> 
>     const c = new C;
> 
> because "auto" is what you use in the absence of any other attribute. In this case, it suffices to create a new C, and then assign it to a const-thereafter variable.

I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl

Dee Girl Wrote:

> Janice Caron Wrote:
> 
> > On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> > >  void main(string[] args)
> > >  {
> > >     auto c = new const C;
> > >  }
> > >
> > >  Does not compile. But if I change to const(C) it does compile. It is a bit unusual that parens make such a big difference. Thank you, Dee Girl
> > 
> > When it comes to parens-version versus non-parens-version, it's not really a problem if one of the two doesn't compile. It would be a bigger problem if both compile, but behave differently.
> > 
> > But I agree with you. "new const C" should behave like "new const(C)".
> > 
> > However, what you probably should have written is:
> > 
> >     const c = new C;
> > 
> > because "auto" is what you use in the absence of any other attribute. In this case, it suffices to create a new C, and then assign it to a const-thereafter variable.
> 
> I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl


Ahh the Japs . Exponents of the art of seeming respectful whilst telling you you are a bloody idiot . This ones not so good at it though.

On Sat, 10 May 2008 12:35:22 +0400, Ty Tower <towerty@msn.com.au> wrote:

> Dee Girl Wrote:
>
>> Janice Caron Wrote:
>>
>> > On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>> > >  void main(string[] args)
>> > >  {
>> > >     auto c = new const C;
>> > >  }
>> > >
>> > >  Does not compile. But if I change to const(C) it does compile. It  
>> is a bit unusual that parens make such a big difference. Thank you, Dee Girl
>> >
>> > When it comes to parens-version versus non-parens-version, it's not
>> > really a problem if one of the two doesn't compile. It would be a
>> > bigger problem if both compile, but behave differently.
>> >
>> > But I agree with you. "new const C" should behave like "new const(C)".
>> >
>> > However, what you probably should have written is:
>> >
>> >     const c = new C;
>> >
>> > because "auto" is what you use in the absence of any other attribute.
>> > In this case, it suffices to create a new C, and then assign it to a
>> > const-thereafter variable.
>>
>> I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl
>
>
> Ahh the Japs . Exponents of the art of seeming respectful whilst telling you you are a bloody idiot . This ones not so good at it though.
>
>

Please, stop it.

Koroskin Denis wrote:
> On Sat, 10 May 2008 12:35:22 +0400, Ty Tower <towerty@msn.com.au> wrote:
> 
>>
>>
>> Ahh the Japs . Exponents of the art of seeming respectful whilst telling you you are a bloody idiot . This ones not so good at it though.
>>
>>
> 
> Please, stop it.

The original message seems to have been deleted (thanks W!), so I'll have to answer to your post instead.

>
> downs wrote:
> Ahh the Ty. Insulting people whilst somehow avoiding getting their messages kicked off the list. This one's not so good at it though.
>

On Sat, 10 May 2008 06:51:21 +0100, Dee Girl <deegirl@noreply.com> wrote:

> Janice Caron Wrote:
>
>> On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>> >  void main(string[] args)
>> >  {
>> >     auto c = new const C;
>> >  }
>> >
>> >  Does not compile. But if I change to const(C) it does compile. It is  
>> a bit unusual that parens make such a big difference. Thank you, Dee Girl
>>
>> When it comes to parens-version versus non-parens-version, it's not
>> really a problem if one of the two doesn't compile. It would be a
>> bigger problem if both compile, but behave differently.
>>
>> But I agree with you. "new const C" should behave like "new const(C)".
>>
>> However, what you probably should have written is:
>>
>>     const c = new C;
>>
>> because "auto" is what you use in the absence of any other attribute.
>> In this case, it suffices to create a new C, and then assign it to a
>> const-thereafter variable.
>
> I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl

It could know and use that but is that really a good idea?
I can imagine a class which had an invariant constructor that set up some sort
of mutex to prevent modification whereas its mutable counterpart did not.
I would hate to try and unravel code like that while debugging.
Its the sort of thing only the compier should need to know about.
That being the case the equals is just syntactic sugar like in C++.

const c = new C;

is identically equivalent to

const c(new C);

and:

const c(new const c);

Koroskin Denis wrote:
> On Sat, 10 May 2008 12:35:22 +0400, Ty Tower <towerty@msn.com.au> wrote:
> 
>> Dee Girl Wrote:
>>
>>> Janice Caron Wrote:
>>>
>>> > On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>>> > >  void main(string[] args)
>>> > >  {
>>> > >     auto c = new const C;
>>> > >  }
>>> > >
>>> > >  Does not compile. But if I change to const(C) it does compile.
>>> It is a bit unusual that parens make such a big difference. Thank you, Dee Girl
>>> >
>>> > When it comes to parens-version versus non-parens-version, it's not really a problem if one of the two doesn't compile. It would be a bigger problem if both compile, but behave differently.
>>> >
>>> > But I agree with you. "new const C" should behave like "new const(C)".
>>> >
>>> > However, what you probably should have written is:
>>> >
>>> >     const c = new C;
>>> >
>>> > because "auto" is what you use in the absence of any other attribute. In this case, it suffices to create a new C, and then assign it to a const-thereafter variable.
>>>
>>> I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl
>>
>>
>> Ahh the Japs . Exponents of the art of seeming respectful whilst telling you you are a bloody idiot . This ones not so good at it though.
>>
>>
> 
> Please, stop it.

let me just post my thanks to the Mozilla foundation for making
Thunderbird such a good product that filters out garbage like the above.
Denis, You really should not answer his posts cause then innocent people
get exposed to his posts, quoted in your replies. Why would you help him
in such a way, huh?
please add a filter to your newsreader. it's simple and much more
environment friendly.
--Yigal

Bruce Adams Wrote:

> On Sat, 10 May 2008 06:51:21 +0100, Dee Girl <deegirl@noreply.com> wrote:
> 
> > Janice Caron Wrote:
> >
> >> On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> >> >  void main(string[] args)
> >> >  {
> >> >     auto c = new const C;
> >> >  }
> >> >
> >> >  Does not compile. But if I change to const(C) it does compile. It is
> >> a bit unusual that parens make such a big difference. Thank you, Dee Girl
> >>
> >> When it comes to parens-version versus non-parens-version, it's not really a problem if one of the two doesn't compile. It would be a bigger problem if both compile, but behave differently.
> >>
> >> But I agree with you. "new const C" should behave like "new const(C)".
> >>
> >> However, what you probably should have written is:
> >>
> >>     const c = new C;
> >>
> >> because "auto" is what you use in the absence of any other attribute. In this case, it suffices to create a new C, and then assign it to a const-thereafter variable.
> >
> > I respectfully disagree, Janice-san. The const subject is of big interest to me and I read many times on the website about it. I think in general it is better to write new const(C) but not new C and then use it to assign a const. It is similar to invariant(C) and it is impossible to construct a new C and then assign it to invariant(C) object. In Andres document from ACCU he shows how invariant constructor must know that object being constructed is invariant. And the same a const constructor could know that the object being constructed is const and use that information. Thank you, Dee Girl
> 
> It could know and use that but is that really a good idea?
> I can imagine a class which had an invariant constructor that set up some
> sort
> of mutex to prevent modification whereas its mutable counterpart did not.
> I would hate to try and unravel code like that while debugging.
> Its the sort of thing only the compier should need to know about.

There could be a simpler case. A const C can have more sharing than an not const C. If the constructor does not know this will be const then it must assume this will be mutated.

And there is one other case. If a const(C) is constructed the invariant constructor can work because invariant is a subtype of const.

> That being the case the equals is just syntactic sugar like in C++.
> 
> const c = new C;
> 
> is identically equivalent to
> 
> const c(new C);
> 
> and:
> 
> const c(new const c);

Is that true? I tried to compile these codes and it does not work. Thank you, Dee Girl

Reply to ty,

> Ahh the Japs . Exponents of the art of seeming respectful whilst
> telling you you are a bloody idiot . This ones not so good at it
> though.
> 

You overstate your case. I have see the suffix -san used by more non Japanese than otherwise. And IIRC a  number of us yanks around here speek the language as well.

BCS wrote:
> Reply to ty,
> 
>> Ahh the Japs . Exponents of the art of seeming respectful whilst telling you you are a bloody idiot . This ones not so good at it though.
>>
> 
> You overstate your case. I have see the suffix -san used by more non Japanese than otherwise. And IIRC a  number of us yanks around here speek the language as well.
> 

I'm starting to feel disappointed. Why do people continue to respond to
this message? common people! what's the point in filtering if people
consider that type of message worthy of a response and a quote?
Maybe we should move to a registration-required model whereby ty's login
would be removed and blocked a long time ago since it's hardly his first
racist remark.

--Yigal