Final vs. never vs. null

[Simn]

Aligns the behavior of null and never field access on anonymous structure types. See #7838 for more information.

closes #7838

[Simn]

@back2dos: Could you double-check https://github.com/HaxeFoundation/haxe/blob/71ee35b831fa0733dc484978b123d015e4e12d24/tests/unit/src/unit/TestFieldVariance.hx for accuracy?

[ncannasse]

The @back2dos type checker is not very fast but can deal with infinite recursions better than the compiler ;)

…

On Mon, Mar 18, 2019 at 4:33 PM Simon Krajewski ***@***.***> wrote: @back2dos <https://github.com/back2dos>: Could you double-check https://github.com/HaxeFoundation/haxe/blob/71ee35b831fa0733dc484978b123d015e4e12d24/tests/unit/src/unit/TestFieldVariance.hx for accuracy? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8011 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwPPjjt-6ZxNKHYqK2jQzujGM7_Z5ks5vX7HMgaJpZM4b5sxq> .

[back2dos]

Uhm, there's still a type hole:

// not possible, for good reasons:
t(typeError(finalField = nullField));
// does the same but compiles just fine:
neverField = nullField;
finalField = neverField;

One of the two assignments should fail, and I think it'd be better if the latter did. Non-final fields don't unify with final fields, while the converse is true. It's a simple and sound rule.

Is still think there's another issue: To me never is a hint for classes only and I think it'd be best to really be clear about what it means for structures / interfaces. Right now, it is broken. In prior exchanges Simn has maintained that @:privateAccess is some uncontrollable type-system-subverting magic that is supposed to not work. I disagree with that alone, but the problem is way larger than that. You can use @:allow / @:access or even plain subtyping to get write access to a field that's not there and will therefore crash on static platforms:

class Test {
  static function main() {
    try {
      new Foo().bar();
      trace('worked');
    }
    catch (e:Dynamic) {
      trace('fail $e');
    }
  }
}

interface IFoo {
  var foo(get, null):Int;
}

class Foo implements IFoo {
  public var foo(get, never):Int;
  function get_foo() return 42;
  public function new() {}
  public function bar() {
    var foo:IFoo = new Foo();
    foo.foo = 42;
  }
}

I think there are really two different options:

1. disallow private access via null on structures / interfaces and then consider null and never fully equivalent. Meaning foo.foo = 42; shouldn't compile. Arguably, that could be fixed by just not allowing private access to implemented interfaces (which we probably really shouldn't allow in the first place), but that would still leave the option to gain access via @:allow / @:access and unless that's now also considered a subversion of the type system, it requires fixing.
2. keep it as is, then never MUST NOT unify with null, because null demands the presence of a physical field (a difference that should not matter, but begins to if there's a way to access the field). Meaning public var foo(get, never):Int;

I absolutely prefer the first option. It's perfectly sound and very unlikely to break code. What's more, I just don't see the use case for private access on null fields for interfaces / structures.

[Simn]

Fixed the type hole.

That interface situation is another bug we should fix. That is a declaration-site problem because the implementer should not have more restrictive access than the interface.

I don't think access control should subvert never. In which concrete case does this happen?

[back2dos]

Like so:

class Test {
  @:access(IFoo)
  static function main() {
    try {
      var foo:IFoo = new Foo();
      foo.foo = 42;
      trace('worked');
    }
    catch (e:Dynamic) {
      trace('fail $e');
    }
  }
}

interface IFoo {
  var foo(get, null):Int;
}

class Foo implements IFoo {
  
  public var foo(get, never):Int;
  function get_foo() return 42;
  public function new() {
  }
}

And if we can agree that that shouldn't compile, perhaps you could find it in you to give me a more tangible argument on why it's a good idea to still have it compile with @:privateAccess and then fail at runtime?

[Simn]

That is the same issue as before. The problem here isn't the access but the declaration. I think that class should not exist like that in the first place.

We have to distinguish declarative subtyping (interfaces) from structural subtyping. A null write-access on an interface variable tells me that the implementing class may access this field. A null write-access on a structure tells me that nobody can access it and thus makes it equal to never. So while you group interfaces with structures in this discussion, I group them with classes.

However, thinking about it like that, I agree that @:privateAccess should not be allowed to subvert access through structures. Access control (which is really more accurately described as visibility control) should already not allow to influence structures.

So to summarize:

• @:privateAccess on structure field should do nothing
• classes should not be allowed to implement a null access as never

[Simn]

Thinking about this again, it might actually be desirable for a class to restrict itself to not access a field. However, this isn't compatible with our definition of what a physical field is, as you've demonstrated. This would require tagging these fields if they come from an interface, but at that point things get confusing and I'm not sure it's worth the complications.

Either way, I'd like to merge this PR because the changes should be good. We can discuss the interface and @:privateAccess situation a bit later.

[back2dos]

Yep, as far as final vs. non-final is concerned, I think we're good ;)