On Friday, 18 August 2023 at 10:48:45 UTC, sighoya wrote:

Easy-peasy:

import std;

/**
* Note this type and enum ideally should be in separate module, to properly hide VoldemortType from rest of the code.
**/
private struct VoldemortType {
    private string message;

    public void say(string post) const {
        writeln(message, " ", post);
    }

    public bool opEquals(Message other) const {
        return other.message == this.message;
    }

    public void sayAlso(Message other, string forSubject) const {
        this.say(forSubject);
        other.say(forSubject);
    }
}

public enum Message : VoldemortType {
    hello = VoldemortType("hello"),
    bye = VoldemortType("bye")
}

void decorate(Message message, string decoration, string subject) {
    std.stdio.write(decoration, " ");
    message.say(subject ~ " " ~ decoration);
}

void main()
{
    Message mess = Message.hello;

    mess.say("entity");
    mess.sayAlso(Message.bye, "subject");
    mess.decorate("**", "third-party");

    writeln("Is hello message same as bye?: ", Message.hello == Message.bye);
    writeln("Is mess variable a hello message?: ", mess == Message.hello);
}

As you can see, there is no such cyclicity you've mentioned, and using Message as parameter to a method or free function (for ufcs), doesn't cause any issues.

Still for free functions, you'd have to import them separately from enum, which imho is ok, since you can know that it is an extension, and not a function part of enum behavior.

Best regards,
Alexandru.

On Friday, 18 August 2023 at 12:11:04 UTC, sighoya wrote:

mixin(generateSelectiveImportForTypeAndUFCSCapableFunctionOf!("someModule", "someType")())

Yes. The metaprog in the mixin hides the import, just like what will do a compiler.
"I can find this, but is this result correct given the scope ?".

On Friday, 18 August 2023 at 16:30:00 UTC, user1234 wrote:

Good idea. There are some points which suck however:

• additional code generation time
• enum variable declarations need separate mixin call to include ufcs as well.

I think maybe a more general case allowing importing a type with ufcs methods as well would be a better solution.

However, for methods associated to the enum type instead of the enum value it would be better to allow them to be included in the enum akin how we do it with structs.