Local Table Destructuring

[xHeptc]

rendered

Note: I am fully aware of RFC 'Granural Imports', 'Table Destructing Syntax' proposals made by other people.
My RFC proposes simpler syntax, doesn't require new keywords, and is not limited to top-level scope with the usage of require().

[jackhexed]

const { foo } is valid syntax today, and while it is possible to parse, its really annoying.

[xHeptc]

const { foo } is valid syntax today, and while it is possible to parse, its really annoying.

Is this syntax reserved for future?

[deviaze]

Could you put some simpler examples for clarity, and include notes on how this works with array-likes, classes, and extern types on the RHS?

[jackhexed]

const { foo } is valid syntax today, and while it is possible to parse, its really annoying.

Is this syntax reserved for future?

No, its a function call.

[deviaze]

const { foo } is valid syntax today, and while it is possible to parse, its really annoying.

Is this syntax reserved for future?

This is already valid syntax for a table call on a function named const

const const = function(t: { s: string })
    print(t.s)
    -- do smth with t
end

const { s = "meow" } -- this is a function call

edit: jack hit post first and don't trust the syntax highlighter (it's wrong)

[xHeptc]

const { foo } is valid syntax today, and while it is possible to parse, its really annoying.

Is this syntax reserved for future?

This is already valid syntax for a table call on a function named const

const const = function(t: { s: string })
    print(t.s)
    -- do smth with t
end

const { s = "meow" } -- this is a function call

edit: jack hit post first and don't trust the syntax highlighter (it's wrong)

What about a special character indicating destructuring?

local @{ print, warn } = log
const @{ print, warn } = log

or, if this is not optimal, restricting this destructuring syntax to local declarations (exclude constants)

[Bottersnike]

Optimal way to distinguish destructuring syntax from function call now is to peek after } token and look for = token.

This isn't possible as outlined, at least not trivially. We could consider const {foo=bar} as the simplest case where looking for a = token has failed us. Parsing decisions would need to be made then later decide what it was that was actually parsed.

[xHeptc]

Optimal way to distinguish destructuring syntax from function call now is to peek after } token and look for = token.

This isn't possible as outlined, at least not trivially. We could consider const {foo=bar} as the simplest case where looking for a = token has failed us. Parsing decisions would need to be made then later decide what it was that was actually parsed.

Got it. I've been brainstorming for some time and got two somewhat solutions.

1. Fully restrict destructuring to local declarations, excluding const

2. Currently, the order of parsing is parsePrimaryExpr and then parseStat, which is perfectly normal, what I propose is: pre-check in parseStat, before calling parsePrimaryExpr, when lexer.current() is Name with text const and lexer.lookahead() is {, save a lexer checkpoint, do the scan to the matching }, peek for =, then either restore and parse as a pattern or restore and fall through to the normal parsePrimaryExpr path.

First one is much simpler, but you lose the chance of having restrictions against rebinding your keys.

And the second one is much more complex to implement, even with type annotations,