[Suggestion] Allow a single non-extern overload

[Geokureli]

I would love it if every overloaded method was allowed one overload that was not inline extern, meaning one overload is actually compiled into the source, and available at runtime.

Example

class Test {
	static function main() {
		final tiles = new TileGrid(4, [1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1]);
		trace(tiles.get(0, 3));
	}
}

class TileGrid {
	final columns:Int;
	final data:Array<Int>;

	public function new(columns:Int, ?data:Array<Int>) {
		this.columns = columns;
		this.data = data ?? [];
	}

	inline public function getIndex(x:Int, y:Int) {
		return y * columns + x;
	}

	overload public function get(index:Int) {
		return data[index];
	}

	overload public inline extern function get(x:Int, y:Int) {
		return get(getIndex(x, y));
	}
}

Reasons

Often my pattern for overloads is to have various foo() overloads and a non-inlined fooHelper() that all of the overloads ultimately call. This is fine for the most part but adds obfuscation. There's a secret private method that devs need to use, for reflection, hscript, or overriding the behavior.

One of my go-to ways of changing the functionality of an outdated or badly formed method in flixel, while respecting semver is to overload it and deprecating the old one, however, this is actually a breaking change for the above stated reasons: overrides will throw an error, and hscript will no longer work. People using reflection know they're in dangerous territory, but since most flixel devs don't know how to code without reflection and will resort to shadowing classes without a second thought to remove breaking overloads.

Implementation

In my limited compiler knowledge, giving clear error messages seems like the real challenge here. We need to remove the Error for Invalid modifier: overload is only supported on extern functions, ignore the first non-extern overload method of a certain name and give a new error on the second. I have no idea how hard this is, but I'm banking on the idea that this might be easy, it might be covered by the Duplicate class field declaration : Type.func error with some special check for the overload modifier allowing the compiler to specify both offending signatures

Impact on existing code

None

Confusion around Extern

I'm also somewhat confused by the extern modifier requirement on all overloads. Granted, I'm confused by the extern doc to begin with: I'm under the impression that all inlined methods are not generated, but this suggests some are, with no examples, given. Many overloads just call other methods, so calling them "extern" seems fitting, but what about methods that do not? does it make sense to allow the omission of extern in those?

[tobil4sk]

I'm under the impression that all inlined methods are not generated

inline just means that a function can be inlined if possible, but it still generates the method so it can still be called via reflection or by taking a method reference.

Adding extern on top of that, we say don't generate the method, and only allow it to be used by inlining its body.

For overloads, the problem with having full runtime overloads is that the runtime has to decide which overload implementation to use. Some targets have support for this, but others do not, so it would have to be implemented manually, which adds overhead and complexity. overload extern inline avoids this by saying: this function won't exist at runtime, so we don't need any runtime overload resolution. Instead, the overload resolution is required to happen at compile time (statically) and the function body inlined.

Having a non-extern overload currently wouldn't work, because that implies that the method should still be callable dynamically, but that doesn't work.

[Geokureli]

For overloads, the problem with having full runtime overloads is that the runtime has to decide which overload implementation to use. Some targets have support for this, but others do not, so it would have to be implemented manually, which adds overhead and complexity. overload extern inline avoids this by saying: this function won't exist at runtime, so we don't need any runtime overload resolution. Instead, the overload resolution is required to happen at compile time (statically) and the function body inlined.

Having a non-extern overload currently wouldn't work, because that implies that the method should still be callable dynamically, but that doesn't work.

It seems like the important detail was missed. I'm specifically saying that the compiler should allow one single function implementation in a set of overloaded functions to be a non-extern. In my example, if both get methods were not extern it would give a compile error.

...the runtime has to decide which overload implementation to use.

There will only be one implementation to use at runtime despite multiple being defined at compile time

Edit:

inline just means that a function can be inlined if possible, but it still generates the method so it can still be called via reflection or by taking a method reference.

Petition to get rid of inline extern and have inline and inline_frfr

[tobil4sk]

It seems like the important detail was missed.

Sorry, I was mainly trying to address the "Confusion around extern" part. I think the proposed feature could be doable, since any runtime resolution only has to consider one "real" method.