I know at least two cases which T.init is commonly used.
1. Inside predicate template for type T.
template isSomething(T) {
enum isSomething = is(typeof({
//T t1; // not good if T is nested struct, or has @disable this()
//T t2 = void; auto x = t2; // not good if T is non-mutable type
T t = T.init; // avoid default construct check
...use t...
}));
}
2. Some library utilities that treats object state directly, e.g.
std.conv.emplace
Kenji Hara
2013/5/20 Maxim Fomin <[email protected]>
> On Monday, 20 May 2013 at 00:55:14 UTC, Kenji Hara wrote:
>
>> 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
>>
>>
> I think this should be fixed otherwise @disable this() is compromised.
> What is rationale behind allowing .init?
>
>
