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} is 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.