@disable("reason")

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jan 8 17:19:07 UTC 2020


On Wed, Jan 08, 2020 at 06:06:33AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Wednesday, January 8, 2020 4:54:06 AM MST Simen Kjærås via Digitalmars-d-
> learn wrote:
[...]
> > struct S {
> >      @disable this();
> >      @disable static S init();
> > }
> >
> > This will give sensible error messages anywhere .init is being
> > used. Now, Phobos and other libraries might expect that .init is
> > always working, so this could potentially be a problem.
> 
> That's likely to break a _lot_ of generic code, because init is used
> heavily in template constraints and static if conditions as the way to
> get a value of that type to test.

I think the new(er?) idiom is to use a lambda parameter to get the type
instead. I.e., instead of:

	auto foo(T, U)(T t, U u)
		if (is(typeof(someOperation(T.init))) &&
		    is(typeof(otherOperation(U.init))))
	{ ... }

you'd write:

	auto foo(T, U)(T t, U u)
		if (is(typeof((T t, U u) {
			someOperation(t);
			otherOperation(u);
		})))
	{ ... }

This will work for types T, U that do not have default initialization
(e.g., @disabled this(), like in the OP), types that for whatever reason
have overridden .init, or types that are non-copyable, etc..

Nonetheless, .init is one of those things that are just assumed to
always exist, so overriding it is not advisable.


> It's also actually been argued before that it should be illegal to
> declare a symbol called init on any type, which is one reason why the
> init member was removed from TypeInfo.  I'd strongly advise against
> anyone declaring a struct or class member named init whether it's
> @disabled or not.

Indeed: https://issues.dlang.org/show_bug.cgi?id=7066


T

-- 
Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.


More information about the Digitalmars-d-learn mailing list