Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null safety strictness levels #7745

Closed
RealyUniqueName opened this issue Feb 4, 2019 · 9 comments · Fixed by #7811
Closed

Null safety strictness levels #7745

RealyUniqueName opened this issue Feb 4, 2019 · 9 comments · Fixed by #7811
Assignees
Labels

Comments

@RealyUniqueName
Copy link
Member

RealyUniqueName commented Feb 4, 2019

Something like

--macro nullSafety("pack", Weak)

For TypeScript-like null safety.

And

--macro nullSafety("pack", Strict)

For Kotlin level of strictness.

Rough example to showcase the difference:

function example(o:{field:Null<String>}) {
  if(o.field != null) {
    mutate(o);
    var notNullable:String = o.f;
  }
}

function mutate(o:{field:Null<String>}) {
  o.field = null;
}

The Weak null safety would not complain about such code, while the Strict one will emit an error on var notNullable:String = o.f; because o.f could be changed to null in mutate(o) call.

If different modes are used in the same build, a warning should be emitted and the least strict mode used.

@Gama11
Copy link
Member

Gama11 commented Feb 4, 2019

What about @:nullSafety meta? Would @:nullSafety(false) become @:nullSafety(Off) so you can have @:nullSafety(Weak) and @:nullSafety(Strict)?

@RealyUniqueName
Copy link
Member Author

I don't want to support mixed modes )

@Gama11
Copy link
Member

Gama11 commented Feb 4, 2019

The ability to set it per package doesn't count as "mixed modes"?

@Simn
Copy link
Member

Simn commented Feb 4, 2019

I don't want to support mixed modes )

Any technical reason for that? If we configure this per-field anyway I don't see much of a problem with it.

We could have this:

@:nullSafety(false) // no null-safety checks
@:nullSafety == @:nullSafety(true) == @:nullSafety(Weak) // TypeScript
@:nullSafety(Strict) // Kotlin

@RealyUniqueName
Copy link
Member Author

RealyUniqueName commented Feb 4, 2019

I'm scared that in the end I'll have to support different modes for different expressions in the single method body :)

@RealyUniqueName RealyUniqueName self-assigned this Feb 4, 2019
@Gama11
Copy link
Member

Gama11 commented Feb 4, 2019

@Simn Hm, supporting both Bool and a strictness "enum" seems unnecessary / confusing.. If there's ever typed meta that would turn into something like EitherType<Bool, NullSafetyStrictness>?

("null safety off" also sounds a bit better in my head than "null safety false")

@RealyUniqueName
Copy link
Member Author

That can be like Strict, Weak, Off

@RealyUniqueName
Copy link
Member Author

But then again, if it's supported per package/field, then why not per expression? )

@Simn
Copy link
Member

Simn commented Feb 5, 2019

I guess we don't need the bools. I treated it like it's the existing way to configure, but I suppose we are still free to change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants