Hello D people,

I stumbled upon a weird thing which I don't find in the language documentation. The compiler allows me to define enum functions with enum keyword instead of auto keyword. It gets more weird. It seems like being an actual auto function with the only difference that it doesn't allow const or immutable but inout qualifier in enum-methods.

struct S {
	enum barz(int x) {  // fine
		return x;
	}
	enum foo(int x) inout {  // fine
		return x;
	}
	// can't use 'enum' with those
	auto foox(int x) const inout {
		return x;
	}
	auto bar(int x) const {
		return x;
	}
	auto baz(int x) immutable {
		return x;
	}
}

I'd like to know:

• What does return type enum mean?

  It's definitely not compile-time-static here and it's definitely not required to be assigned to an enum (auto works as well).

• What is the difference to using auto as return value ?

• Why is there no shortform template syntax for enums? I have to write it like this:

template MyEnum(X) {
	enum MyEnum {
		a = X,
		b, c, d
	}
}

Regards!

On Monday, 19 July 2021 at 21:16:57 UTC, Elmar wrote:

It just means auto. Probably it shouldn't be allowed at all, but D's parser is sometimes overly-permissive and will accept things like this even when they don't really make sense.

For example, you can also declare a @nogc variable:

@nogc x = new Object;

The @nogc attribute doesn't do anything here, but the compiler allows it anyway.

On Monday, 19 July 2021 at 21:31:40 UTC, Paul Backus wrote:

The issue is that people misunderstand auto and type inference. It's a variable definition with initializer and a storage class WITHOUT a type.

The grammar is clear though

```
AutoDeclaration:
    StorageClasses AutoAssignments ;

StorageClasses:
    StorageClass
    StorageClass StorageClasses

StorageClass:
    LinkageAttribute
    AlignAttribute
    AtAttribute
    deprecated
    enum
    static
    extern
    abstract
    final
    override
    synchronized
    auto
    scope
    const
    immutable
    inout
    shared
    __gshared
    Property
    nothrow
    pure
    ref
```

@nogc x = new Object;

deprecated x = new Object;

@dummy y = 1;

On Tuesday, 20 July 2021 at 09:15:42 UTC, Patrick Schluter wrote:

```
AutoDeclaration:
    StorageClasses AutoAssignments ;

StorageClasses:
    StorageClass
    StorageClass StorageClasses

StorageClass:
    LinkageAttribute
    AlignAttribute
    AtAttribute
    deprecated
    enum
    static
    extern
    abstract
    final
    override
    synchronized
    auto
    scope
    const
    immutable
    inout
    shared
    __gshared
    Property
    nothrow
    pure
    ref
```

@nogc x = new Object;

You can also do confusing things like this:

@safe x = 12;

D is almost like "just give me whatever, if I can use it then I'll use it, if I can't then I'll skip it.

On Tuesday, 20 July 2021 at 10:09:32 UTC, bauss wrote:

@safe x = 12;

Lol, we could add this to object.d:

//meant to save two characters from auto keyword, e.g. you
//can define @a x = 0; instead of auto x = 0;
struct a{}

I don't think that'd be a good idea though.

On Monday, 19 July 2021 at 21:31:40 UTC, Paul Backus wrote:

@nogc x = new Object;

Thank you all for your answers. I didn't know you can skip auto by using an attribute :-o but I had hoped this would be possible.

Just wait for some time ;-) . I'm going to make this piece of code work, but using a different syntax:

auto x = GC!Object(arg1, arg2);  // allocates using D's GC
auto y = GC!Object.init;         // zero-arg constructor call
@gc a  = new Object;             // @gc represents a "memory contract" assumption
auto z = GC!Object.init!a;       // constructor call with compile-time argument, checks memory contract (statically or dynamically)

I've started work on a simple memory contract library which should allow people to replace the old new keyword with a struct name like GC.

I hope it will make using alternative allocators very simple and will make allocations and memory requirements finally transparent for API users.

On Monday, 19 July 2021 at 21:16:57 UTC, Elmar wrote:

Btw does anybody know why "enum functions" only work with inout but not const or immutable ?

On Thursday, 22 July 2021 at 13:32:48 UTC, Elmar wrote:

By accident, I assume. Nobody really writes "enum functions" so these code paths in the compiler are not well-tested.