What do you think of C#'s non nullability migration strategy: https://learn.microsoft.com/en-us/dotnet/csharp/nullable-migration-strategies

It seems they introduced some switch allowing to see all reference types as nun nullable and throw an error if that's not the case.

Though because of backward compatibility you need to explicitly allow them.

I personally have mixed feelings about this.

On the one hand it's better than two write ClassType! all the time in new code reducing terseness compared to ClassType?.

So instead you only need to append a ? to the class type when it should also allow for null values.

e.g.:

//with strict non nullability flag enabled
Class c=null //error
Class? c=null //okay

On the other hand it feels like a new language dialect, a new color added to your language where you need to think in nullable (legacy) and nonnullable (new world) contexts.

Still like the solution, though.

Your opinion?

On Tuesday, 8 August 2023 at 19:39:22 UTC, sighoya wrote:

//with strict non nullability flag enabled
Class c=null //error
Class? c=null //okay

Neat has it! Class c = null is a compile error, you have to write nullable Class c = null. This is longer than Class?, but that's deliberate, because I want to make nullable classes a bit awkward to slightly discourage their use. The only difference is that null only implicitly converts to nullable Class. It works pretty well, but D prefers that all types have a defined initializer.

Sidenote, just to brag a little: writing this all the time would get annoying.

    Class c = new Class;
    nullable Class2 d = c.instanceOf(Class2);
    if (!d) return false;
    Class2 d = d.notNull;

So in Neat, we can shorten it:

    Class c = new Class;
    Class2 d = c.instanceOf(Class2).case(null: return false);

The problem for D is that you can't introduce a breaking change like non-nullable classes by default gradually, because there's no way to apply a feature flag only to one dub package, for instance. So even if it's optional, you're in effect forcing everybody to upgrade.

On Wednesday, 9 August 2023 at 04:39:59 UTC, FeepingCreature wrote:

So is Neat some sort of D3, a clean and lean version? Sounds interesting. Do you have a roadmap, and most importantly: does Neat support cross-compilation to many different OSes and architectures (like e.g. Zig)?

On Wednesday, 16 August 2023 at 08:50:51 UTC, Chris wrote:

https://neat-lang.github.io/

More like D1.5 version 0.1. I'll make a proper presentation on it at DConf, but it's certainly too alpha to use right now, unless you really like experimental features.

Though it's certainly not the only reason, part of the hope with it is that D can mine it for ideas.

On Wednesday, 16 August 2023 at 10:16:33 UTC, FeepingCreature wrote:

Roadmap:
0.1 - alpha experimental features
...
1.0 - switch all Funkwerk to Neat

:)

On Wednesday, 16 August 2023 at 10:16:33 UTC, FeepingCreature wrote:

I really like the idea of D1.5. Instead of moving on to D3, D2 (or rather "D++") should be shrunk down to D1.5 - lean and clean.

On Wednesday, 16 August 2023 at 10:26:34 UTC, Sergey wrote:

That would be extremely irresponsible and a colossal waste of time.

(But so, so tempting...)

:)

PS: Just to make clear, this will probably never happen. A lot of the ideas in Neat match the style of how we use D at Funkwerk anyways, so switching to Neat would only give us very marginal improvements at best. Realistically, it would cause no end of issues. To be very clear, Neat is currently not at "D1" level, it's maybe at "D 0.100" level. But even when that is fixed, D is and will always be twenty years more mature than Neat, and that's more important for a business, no matter how cute its macros are.