On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

Not necessarily a feature, but I think the absence of hindley milner type inference is a big one. I think that statically typed languages should adopt it or at the very least be influenced by it unless they have a really good reason not too.

Types are completely optional in (vanilla) hindley milner. You can write code that looks like python and still have all the benefits of static typing. It also infers the most general type for the code you write. This makes your code as generic as possible unless you add a type annotation to make it less generic.

I also think that it can help in language design in general. Weak typing and subtyping, features that are generally disliked are incompatible with hindley milner. It gives good answers to what the type of a null pointer and an empty array are without resorting to void pointers and void arrays which feel hacky.

On Tuesday, 12 October 2021 at 06:14:40 UTC, bauss wrote:

But you are do it explicitly, use the more verbose syntax:

alias a = abc => function{ return 123; };

Also you have warning now

On Tuesday, 12 October 2021 at 13:26:34 UTC, Steven Schveighoffer wrote:

IMO the actual answer here is to deprecate the { /* ... */ } syntax for function literals entirely.

Not only is it confusing in the context of => lambdas, it also creates a grammatical ambiguity between function literals and block statements, which results in bugs like issue 21619.

On Tuesday, 12 October 2021 at 16:19:42 UTC, Nick Treleaven wrote:

Currently, the big advantage exceptions have over sum types is that you cannot accidentally ignore an exception. Either you catch it, or it crashes your program.

With @nodiscard, we can eliminate this advantage, and put sum types and exceptions on an equal playing field.

On Tuesday, 12 October 2021 at 16:26:33 UTC, Paul Backus wrote:

One idea I had when bumping into this problem was something like a with statement but you give it some kind of composition operator, and then it joins the statements up implicitly a la do notation in Haskell

On Tuesday, 12 October 2021 at 17:25:52 UTC, max haughton wrote:

You can technically do this already with foreach and opApply, although the result ends up looking kind of goofy:

foreach (b; a)
foreach (c; b)
foreach (d; c)
e;

Desugars to:

a.opApply(b =>
    b.opApply(c =>
        c.opApply(d => e)));

...which is almost the same thing as Haskell's do notation, if you replace >>= with opApply and x <- y with foreach (x, y).

This similarity is perhaps why Scala uses the for keyword for its version of do notation.

On 10/12/21 12:22 PM, Paul Backus wrote:

It's not a terrible idea. But I think there are hacks all over the place that enjoy the short syntax. One that I know of is to get the parent scope of a location:

alias parentScope = __traits(parent, {});

Now, changing this to __traits(parent, (){}) probably isn't a horrible update to require, but this code breakage is going to seem a little extraneous.

-Steve

On Tuesday, 12 October 2021 at 17:49:10 UTC, Steven Schveighoffer wrote:

alias parentScope = __traits(parent, {});

This syntax is cute, but it's also extremely opaque, and confusing to beginners [1][2]. (){} is not much better, but it at least makes it clear that what you're looking at isn't a normal block statement, and you need to check the documentation/ask in the Learn forum/etc. to find out what it is.

[1] https://forum.dlang.org/post/rzboijdfewehucrmztyc@forum.dlang.org
[2] https://forum.dlang.org/post/i40s2i$271n$1@digitalmars.com