What about defining no-op (unshared) struct keyword used in tandem with Reflect API ? [REQUESTING A COMMENT]

Thank God I stumbled upon this specification as I am very bad at writing one. I just wanted to add a different point of view to this proposal. Consider author's offered unshared struct used with the ES6's built-in Reflect accompanied by the typed-getters utility.

Current EcmaScript (JavaScript) enforces the following syntax (example uses JSDocs annotation)

import '@gloch96/typed-getters/src/index.mjs';

/**
 * @type {struct}
 */
class Coords {

    static x = 2;
    static y = 3;

}

/**
 * @type {interface}
 */
class Calculator {

    static squareArea({x, y}) {
        return (
            x?.isInt * y?.isInt
        );
    }

    static circArea({x}) {
        let radius = x?.isInt;
        return (
            ( radius * (2 * Math.PI) )
        );
    }

}

console.log(
    "\n\n"
    ,
    Reflect.apply(
        Calculator.squareArea, null, [Coords]
    ),
    "\n\n"
    ,
    Reflect.apply(
        Calculator.circArea, null, [Coords]
    )
);

The following proposal would reduce code by not forcing developers to use JSDocs annotations. Consider the following pseudo-code example with proposal in mind:

import '@gloch96/typed-getters/src/index.mjs';

struct Coords {
    static x = 2;
    static y = 3;
}

/**
 * ["implicit struct as interface"]
 * 
 * Alternatively, instead of defining another keyword for interface, the interface itself could be replaced by the same "struct" keyword, but IF AND ONLY IF method signatures used: 
 * such struct automatically, yet implicitly, would be considered as an interface.
 * ===
 * Getting back to Golang's (Go) Interface naming convention, the interface has "-(i)er", "-or" name endings e.g. Printer, Notifier, Calculator : by simply following naming convention "struct" keyword would be sufficient to cover both i.e. "struct" and "interface" keywords.
 * {@link https://go.dev/doc/effective_go#interface-names}
 */
struct Calculator {

    static squareArea({x, y}) {
        return (
            x?.isInt * y?.isInt
        );
    }

    static circArea({x}) {
        let radius = x?.isInt;
        return (
            ( radius * (2 * Math.PI) )
        );
    }

}

console.log(
    Reflect.apply(
        Calculator, null, [Coords]
    ),
    Reflect.apply(
        Calculator, null, [Coords]
    )
);

To summarise, using JSDocs is perhaps de facto standard behaviour for a weakly-typed languages like JavaScript, however using it with utilities like typed-getters or fully-fledged libraries, such as is, including features for the (un-)shared struct itself mentioned in the proposal, I believe this could become a fully fledged solution to novice JavaScript developers or people who still think migrating from vanilla JavaScript to TypeScript, that eventually would be stripped back to vanilla JavaScript after transpilation, yet in more optimised fashion.

tc39 / proposal-structs

What about defining no-op (unshared) struct keyword used in tandem with Reflect API ? [REQUESTING A COMMENT] #25