On Tuesday, 20 July 2021 at 15:50:49 UTC, russhy wrote:

Terrible, just terrible.

On Thursday, 22 July 2021 at 03:28:44 UTC, Paul Backus wrote:

enum E : string { x = "y", y = "x" }

E e = "y"; // what happens here?

The VRP mechanics do not currently let that compile, so nothing will break. it would be equal to E e = E.y; E e = cast(E)"y" on the other hand would still be E e = E.x, as it's now.

Now, I admit that difference between implicit and explicit cast is confusing and a weakness. Maybe the syntax should be E e = ".y" instead to avoid the difference in behaviour between implicit and explicit cast.

On Thursday, 22 July 2021 at 14:05:53 UTC, Dukc wrote:

enum E : string { x = "y", y = "x" }

E e = "y"; // what happens here?

Ok, now imagine you're new to D and don't know about this feature. What are you going to think E e = ".y" does?

Using string-literal syntax for things that aren't actually string literals is just asking for confusion.

On 7/21/21 7:59 PM, Walter Bright wrote:

I'm not asking for anything. What I'm saying is the feature in Swift (called "dot syntax") that allows one to use .enumMember wherever a specific enum is required, is not the same as creating symbol aliases for all the enum members in your namespace (or in module namespace). The Swift feature is contextual based on the expression type, and doesn't require any extra machinery around it. This means that you don't have weird ambiguities when you have multiple enums as parameters, or names that are local that might override the names. e.g.:

enum A
{
   one,
   two,
   three
}

enum B
{
   one,
   two,
   three
}

void foo(A a, B b) {... }

// how to call foo without having to specify `A.one` or `B.one`?

In Swift, .symbol is specifically for type properties, and fit perfectly for enums (and other things, see here). It does not have the meaning that D has, so it can get away with this.

I don't expect D to implement such a thing, and yes, you can do mixin hacks or with statements (though there are drawbacks to both). Just saying .member instead of FullEnumType.member whenever a FullEnumType is required is a nice feature of Swift, and I would like to see something like it in D, but I can live without it. BUT if it were to be implemented, obviously .symbol doesn't work. That's why I proposed a shortcut to mean "property of the required type" such as #.symbol.

-Steve

On Wednesday, 21 July 2021 at 15:13:36 UTC, Petar Kirov [ZombineDev] wrote:

IMO D's target-typed literals (also called "polysemous literals") are also a misfeature. They lead to weird, unintuitive situations where seemingly-equivalent code has different behavior; for example:

import std.stdio;

void fun(double[] arr) { writeln("double"); }
void fun(T)(T[] arr) { writeln(T.stringof); }

void main()
{
    fun([1, 2, 3]);
    auto arr = [1, 2, 3];
    fun(arr);
}

A language with fully-context-aware type inference would infer both arrays as double[]. A language with fully-context-independent type inference would infer both as int[].

In D, however, we get the worst of both worlds: type inference is mostly context-independent (so we have to add type annotations even in cases that are unambiguous), but there are a few special cases where context is taken into account (so we have to be mindful of context when refactoring, since a change in context could change the inferred type of an expression).

On Thursday, 22 July 2021 at 16:41:30 UTC, Paul Backus wrote:

import std.stdio;

void fun(double[] arr) { writeln("double"); }
void fun(T)(T[] arr) { writeln(T.stringof); }

void main()
{
    fun([1, 2, 3]);
    auto arr = [1, 2, 3];
    fun(arr);
}

It’s not so bad IMO. Type inference in D isn’t far from just “forward, one step at a time”, which is easy to understand but still very powerful.

On Thursday, 22 July 2021 at 17:28:02 UTC, Walter Bright wrote:

You mean this isn't true anymore?
https://dlang.org/spec/module.html#name_lookup