Thread overview
What is that "enum function" supposed to be ?
Jul 19
Elmar
Jul 20
bauss
Jul 20
Dukc
Jul 22
Elmar
Jul 20
bauss
Jul 22
Elmar
July 19

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!

July 19

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

>

I'd like to know:

  • What does return type enum mean?

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.

July 19
On Mon, Jul 19, 2021 at 09:16:57PM +0000, Elmar via Digitalmars-d wrote: [...]
> 	enum barz(int x) {  // fine
> 		return x;
> 	}
[...]

That's hilarious.  Part of me almost wants to suggest this as syntax for CTFE-only functions. :-D  I.e.,

	enum fun(int x) { ... }

would be equivalent to:

	auto fun(int x) {
		if (_ctfe) { ... }
		else assert(0);
	}


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
July 20
On Monday, 19 July 2021 at 22:28:01 UTC, H. S. Teoh wrote:
> On Mon, Jul 19, 2021 at 09:16:57PM +0000, Elmar via Digitalmars-d wrote: [...]
>> 	enum barz(int x) {  // fine
>> 		return x;
>> 	}
> [...]
>
> That's hilarious.  Part of me almost wants to suggest this as syntax for CTFE-only functions. :-D  I.e.,
>
> 	enum fun(int x) { ... }
>
> would be equivalent to:
>
> 	auto fun(int x) {
> 		if (_ctfe) { ... }
> 		else assert(0);
> 	}
>
>
> T

You're onto something.
July 20

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

>

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

>

I'd like to know:

  • What does return type enum mean?

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.

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
```
>

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

@nogc x = new Object;

deprecated x = new Object;

@dummy y = 1;

>

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

July 20

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

>

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

>

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

>

I'd like to know:

  • What does return type enum mean?

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.

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
```
>

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

@nogc x = new Object;

deprecated x = new Object;

@dummy y = 1;

>

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

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.

July 20

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

>

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.

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.

July 22

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

>

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

>

I'd like to know:

  • What does return type enum mean?

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.

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.

July 22

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 ?

July 22

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

>

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 ?

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