Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[Kenji Hara]

Unfortunately this is currently not a bug.
T.init provides "default initialized" object image, and it *does not*
provide "default constructed" object. The difference is important.

That is already documented in lanugage reference.
http://dlang.org/property#init

> Note: .init produces a default initialized object, not default
constructed. That means using .init is sometimes incorrect.
> 1. If T is a nested struct, the context pointer in T.init is null.
> 2. If T is a struct which has @disable this();, T.init might return a
logically incorrect object.

Kenji Hara

2013/5/20 Maxim Fomin <maxim at maxim-fomin.ru>

> On Saturday, 18 May 2013 at 20:39:29 UTC, Walter Bright wrote:
>
>> On 5/18/2013 1:22 PM, deadalnix wrote:
>>
>>> Many are, but I think that isn't the point we are discussing here.
>>>
>>> Removing all holes in @disable this will require the same sacrifices at
>>> the ends
>>> than default constructor would. For isntance, what should happen in this
>>> case :
>>>
>>> S[] ss;
>>> ss.length = 42;
>>>
>>> if S has @disable this ?
>>>
>>
>> Already reported:
>>
>> http://d.puremagic.com/issues/**show_bug.cgi?id=10115<http://d.puremagic.com/issues/show_bug.cgi?id=10115>
>>
>
> New case, will report it:
>
>
> struct S
> {
>    int a;
>    @disable this();
>    this(int) { a = 1; }
>    ~this() { assert(a !is 0); }
>    alias a this;
>    int opCall() { return a; }
> }
>
> void main()
> {
>    switch (S.init())
>    {
>       case 0:
>          assert(0); //oops
>       default:
>    }
> }
>
> By the way, here is another bug.
>
> I think there is disagreement about @disable reliability and usefulness
> and similar issues (@safe reliability too) due to different attitude to
>  the problem:
> - As a language designer I care about whether some feature is claimed to
> solve some problem - and that all, I put it on a slide as lang advantage;
> - As a programmer who writes medium importance code I care whether the
> feature stops me from making bugs unintentionally. If it does, than I
> consider that the feature works.
> - As a programmer who writes critical code I care whether feature prevents
> from problem, even made deliberately, and if it doesn't, than the feature
> isn't reliable. It doesn't mean that it is totally useless, but it does
> mean that its reliability commitments are cheap.
>
> Since in system language there is plenty of ways to deliberately pass
> invalid data to the place where some validity assumptions were made,
> @disable is a broken feature.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130520/c795995b/attachment-0001.html>