HaxeFoundation / HaxeFoundation/haxe

Field should be public as requested by interface

Open
#12,268 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Haxe
Stars
6.9k
Forks
715
Avg merge
2d 2h
Merged PRs (30d)
11

Description

I've been wondering about this particular error situation:

```haxe
interface I {
function f():Void;
}

class C implements I {
public function new() {}

function f() {} // Field f should be public as requested by I
}

function main() {}
```

In my mind, having "private" fields which we can unlock by assigning a class to an interface is a useful feature, not an error. It doesn't break into the classes personal space because it decides which interfaces to implement itself, which means we're not "hacking" it from the outside. Instead, we would allow passing around different "views" to the same object in the form of interfaces.

I understand that this would be problematic if the actual runtime access was a problem, which could be the case for truly private fields in some situations. But our `private`, which is actually `protected`, is generated as `public` anyway for various reasons.

At first I wanted to propose allowing `@:privateAccess` on interfaces to explicitly support this, but I struggle to see why this should be disallowed on _any_ interface implementation. Am I missing something?

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the compiler logic that checks interface implementations for required public fields, using the Haxe example in this issue as the reproducer. Determine whether allowing a non-public implementation is intended and define the compatibility and access rules before changing behavior. Done means the decision is implemented and covered by compiler tests for interface visibility.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.