[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[SHOO]

(2010/11/04 2:37), Jonathan M Davis wrote:
> On Wednesday, November 03, 2010 10:09:03 SHOO wrote:
>> (2010/11/03 2:47), Michel Fortin wrote:
>>> :
>>> :
>>> :
>>
>> I don't think so.
>> @safe code cannot forbid to bring out the address:
>> http://ideone.com/rMl5i
>>
>> @safe only forbid pointer operation:
>> http://ideone.com/8nWRP
>
> If you're basing that on what the compiler currently complains about, then I'm
> not sure that that's a very good measurement since @safe, @trusted, and @system
> still need a fair bit of work, as I understand it, before they're really going
> to be correct. So, even if you can currently do something in @safe mode, that
> doesn't mean that you should be able to, and if you can't do something in @safe
> mode, that doesn't necessarily mean that you're not supposed to be able to
> either.
>

I cannot judge whether or not @safe should admit the copy of the 
pointer. However, I think that this argument is significant.

- http://ideone.com/bJJA3
- http://ideone.com/MsP5V
- http://ideone.com/2gwBs
- etc.

Some examples seems to promote troublesomeness.

>> Rather I am strong in interest about this problem.
>> I think that RAII is a main reason that a constructor and a copy
>> constructor and a destructor were added to struct.
>> I suspect that it is the root of all evils that D cannot handle RAII well.
>
> I don't know if it's the root of _all_ evil, but I agree that it's a serious
> problem. Unfortunately, we'd probably need to change the language so that a
> struct's init wasn't completely known at compile-time but rather was partially
> computed at runtime if we want to _really_ solve the problem, and I question
> that we'll ever get Walter to sign off on that one. However, the lack of default
> constructors for structs is one of - if not _the_ - largest design flaw in the
> language IMO.
>
> - Jonathan M Davis

I agree with you that, '_all_' may be exaggerated　:)

Surely, I want the default constructer of struct very much.
Otherwise we should avoid handling an object by a struct. Because there 
is the function of that purpose in class.
'final scope class' seems to be an attractive name.

--
SHOO