www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is disable obsolete?

reply Brother Bill <brotherbill mail.com> writes:
It doesn't seem like modern D needs the  disable feature.

If a struct has a user provided constructor, then the default 
constructor is removed.

Are there any cases where  disable is useful in modern D?
Aug 05
next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 6 August 2025 at 00:42:43 UTC, Brother Bill wrote:

 It doesn't seem like modern D needs the  disable feature.

 If a struct has a user provided constructor, then the default 
 constructor is removed.

 Are there any cases where  disable is useful in modern D?


it always seemed like a naturally extension of ` deprecate` and 
deprecate isnt going anywhere; I dont even know if the ` disable 
this()` was a intentional feature, it seems like a ye old 
documenting what happens as if intentional.

Nothing id use, but someone has this theory that deprecation 
should be a long cycle, these provide tools to auto generate 
error messages and phoebes (pretends to) practice this cycle
Aug 05
prev sibling next sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 6 August 2025 at 00:42:43 UTC, Brother Bill wrote:

 If a struct has a user provided constructor, then the default 
 constructor is removed.


Is it?

```d
struct S
{
     int i;
     this(int);
}

void main()
{
     S s = S(); // OK
}
```
Aug 06
prev sibling next sibling parent Kagamin <spam here.lot> writes:
` disable this(this);`
Aug 06
prev sibling next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Aug 06, 2025 at 12:42:43AM +0000, Brother Bill via Digitalmars-d-learn
wrote:

 It doesn't seem like modern D needs the  disable feature.
 
 If a struct has a user provided constructor, then the default
 constructor is removed.


This is incorrect.


T

-- 
The Axiom of Choice is obviously true, the well-ordering principle obviously
false, and who can tell about Zorn's lemma? -- Jerry Bona
Aug 06
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 5, 2025 6:42:43 PM Mountain Daylight Time Brother Bill via
Digitalmars-d-learn wrote:

 It doesn't seem like modern D needs the  disable feature.

 If a struct has a user provided constructor, then the default
 constructor is removed.


D structs don't really have default constructors. Types in general in D have
default initialization, which normally means that variables of that type are
initialized with their init value, which is determined at compile time. The
exception would be non-static nested structs which also have an implicit
context pointer, and those structs get default-initialized with their init
value _plus_ their context pointer gets initialized with the address of
their outer scope (whereas if you explicitly initialize such a struct with
their init value, you get a null context pointer). Either way, there is no
constructor involved. The compiler is blitting the type's init value into
the object's memory.

You can use S() to get the default-initialized value of a struct (which in
almost all cases is the same thing is S.init), but either way, it exists
whether you declare any constructors for a struct or not. Both

    S s;

and

    auto s = S();

will give you the default-initialized value of that struct, and that occurs
whether the struct has any constructors or not.

What you lose when you declare a constructor for a struct is the implicit
constructor syntax. That is, if you have something like

    struct S
    {
        int i;
        string s;
        bool b;
    }

then syntactically, it's like you have three different constructors,

    this(int)
    this(int, string)
    this(int, string, bool)

allowing you to "call" them with expressions such as S(42), S(19, "foo"),
and S(27, "bar", false). But the compiler doesn't actually give the struct
any constructors (e.g. when you list all of the members of such a struct, no
constructors are there). You just get the constructor syntax.

And when you declare any normal constructors (as opposed to something like a
copy constructor or postblit constructor), then you lose that syntax and can
only use the constructors which have been declared.


 Are there any cases where  disable is useful in modern D?


     disable this();

will disable default initialization for a struct. So, then both

    S s;

and

    auto s = S();

will fail to compile. You're then forced to explicitly call a constructor to
initialize the struct.

Similarly,

     disable this(this);

will disable copying a struct, and

     disable void opAssign(S);

would disable the assignment operator for a struct.

In fact, you can use  disable on any symbol to make it so that it cannot
be used. In most cases, you'd just use it to disable something that the
compiler would normally automaticaly provide, but what it does in the
general case is allow you to have a symbol which will be found via symbol
resolution but which can't actually be used.

So, you could actually make it so that a struct couldn't be used with a
function via UFCS, because it had an  disabled member function with the same
name. Similarly, you could declare a variable and then make it unusable with
 disable. Whether that's actually useful in practice is debatable, but
 disable is a general mechanism which makes it so that a symbol exists but
isn't usable. It isn't restricted to a particular set of symbols.

But either way, at minumum, it's useful for disabling some of the symbols
that the compiler would normally generate automatically, giving you the
ability to do things like make a struct uncopyable or unassignable.

- Jonathan M Davis
Aug 06