Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1 (page 21)

On Monday, 28 November 2022 at 07:06:56 UTC, Max Samukha wrote:

Why is that absurd?

This:

struct Entity
{
    enum Kind
    {
    }

    Kind entity;
}

instead of this:

enum EntityKind
{
}

struct Entity
{
    EntityKind entity;
}

is a common practice.

About nesting in general I've replied to ryuukk_ at https://forum.dlang.org/post/gjhvbrehodkabzvewopx@forum.dlang.org

In this example there's little difference, between having to type (or not) either Entity.Kind or EntityKind. It's indeed a good example how nesting without private data is a purely stylistic namespacing choice. (So imo no one forces you to use it to an extent that requires you to type too much or otherwise makes your life difficult.)

November 30, 2022

Re: Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1

Posted by Quirin Schroll
in reply to XavierAP

Permalink

Quirin Schroll

Posted in reply to XavierAP

Permalink

On Monday, 28 November 2022 at 09:33:56 UTC, XavierAP wrote:

I didn't mean to be dismissive. And for the record I'd be OK with adding to D most kinds of inference as long as it didn't require new syntax (such as $ or adding to .) and were 100% sure and safe. This might be possible for enums at least in initializations or even assignments (?) but it's not the current DIP (and there are probably other difficulties even with this).

There isn’t much that’s 100% safe in a pragmatic context. Inference for switch, initialization and assignment is possible except special compound assignments like those that lower to opIndexAssign, where the left-hand side operand need not have a type at all. Even then, a best-effort strategy might still be useful and work in almost all cases.

In many cases, an assignment lhs = rhs could be lowered to

lhs = (){ with (typeof(lhs)) return rhs; }();

This might not be foolproof, but it’s probably “safe unless you do obvious stupid”.

Forums