[vim9script] Forward declarations for classes?

[Lifepillar]

Consider the following example:

class Rgb
this.r: float
this.g: float
this.b: float

def ToHsv(): Hsv
# ...
enddef
endclass

class Hsv
this.h: float
this.s: float
this.v: float

def ToRgb(): Rgb
# ...
enddef
endclass

In a scenario like the above, the return type of ToHsv() must be changed
to `any`. Is a mechanism to make the above code legal being considered?

Of a similar flavour:

class X
def Clone(): X
# Return a copy of this
enddef
endclass

Currently, Clone() must be typed as `any`.

Thanks,
Life.

[Bram Moolenaar]

The second one should just work. Currently the class is only defined
when "endclass" is found. Doing it earlier is more implementation work,
but it should not require anything on the user side.

For the first example I'm not sure what the best solution is. There is
a plan to add some kind of typedef, but it would still require something
extra to indicate the actual implementation will follow later.

There is trouble when it's not just the class name that needs to be
known, but also what it contains. Then a forward declaration quickly
becomes a lot of duplicate text. And recursive dependencies need to be
handled, which is also relevant in this example.


--
ARTHUR: Will you ask your master if he wants to join my court at Camelot?!
GUARD #1: But then of course African swallows are not migratory.
GUARD #2: Oh, yeah...
GUARD #1: So they couldn't bring a coconut back anyway...
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Lifepillar]

On 2023-03-26, Bram Moolenaar <Br...@moolenaar.net> wrote:
> The second one should just work. Currently the class is only defined
> when "endclass" is found. Doing it earlier is more implementation work,
> but it should not require anything on the user side.
>
> For the first example I'm not sure what the best solution is. There is
> a plan to add some kind of typedef, but it would still require something
> extra to indicate the actual implementation will follow later.

Typedefs would look super nice to me, but for another reason: type
aliasing would make my code a lot easier to read!

> There is trouble when it's not just the class name that needs to be
> known, but also what it contains. Then a forward declaration quickly
> becomes a lot of duplicate text. And recursive dependencies need to be
> handled, which is also relevant in this example.

Thanks for the thorough reply. This is not a blocker, at least for the
code I write, as `any` is a sufficiently good workaround, which perhaps
requires some extra care with typing in some cases, but nothing
dramatic. Looking forward to seeing these last issues being ironed out!

Life.