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 <ma...@maxim-fomin.ru> > 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? > >