Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/inner destructuring #283

Closed

Conversation

teggotic
Copy link

@teggotic teggotic commented May 6, 2020

No description provided.

@Sija Sija added the language Language feature label May 6, 2020
@Sija
Copy link
Member

Sija commented May 6, 2020

@teggotic Ameba warnings need to be fixed, see failed CI builds.

Copy link
Member

@gdotdesign gdotdesign left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR 👍

There are some larger issues:

  • Tuples can be destructured in statements (try, where, etc...) but enums and arrays can't so we need to restrict the parser for this to only allow type variables
  • The type checker will correctly check things at the first level but not at lower levels, for example this [a, b, [...x,...y,...z], ...c] => { } would not raise an error. We need to do this recursively as well.

@@ -4,6 +4,8 @@ module Mint

alias TypeOrVariable = Type | TypeVariable

alias DestructuringType = ArrayDestructuring | EnumDestructuring | TupleDestructuring
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not necessary and should be replaced with Node

@@ -1,9 +1,11 @@
module Mint
class Ast
class EnumDestructuring < Node
alias EnumDestructuringParameter = DestructuringType | TypeVariable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not necessary.


statements << "const #{js.variable_of(node.items.select(Ast::Spread).first.variable)} = __"
statements
condition = "Array.isArray(#{condition_var_name}) && #{condition_var_name}.length >== #{node.items.size - 1}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be condition = if makes it easier to read.

@@ -1,36 +1,64 @@
module Mint
class Compiler
def _compile(node : Ast::ArrayDestructuring, value)
private macro compile_item!(initial_var, item = item, index = index1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this needs to be a macro?

@@ -31,5 +31,8 @@ module Mint
input: data)
end
end

def parse_destructuring_item
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left over empty method.

@@ -11,7 +12,16 @@ module Mint

option = type_id! EnumDestructuringExpectedOption

parameters = many { type_variable }.compact
parameters = (many do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have only one syntax, in this case with parentheses. This will be a breaking change, but would fix the else branch since there it's not possible to inner destructure.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we want to have a comma between parameters?


scope(variables) do
scope(variables.not_nil!) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to_a instead of not_nil!

@@ -33,6 +33,12 @@ module Mint
"option" => option,
"node" => param,
} unless option.parameters[index]?

case param
when Ast::EnumDestructuring
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other branches should be resolved as well, since they can cause other errors.

@Sija
Copy link
Member

Sija commented Nov 17, 2020

@teggotic Hi, are you willing to continue working on this?

@teggotic
Copy link
Author

@teggotic Hi, are you willing to continue working on this?

You can take it

@gdotdesign
Copy link
Member

Superseded by #593

@gdotdesign gdotdesign closed this May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request language Language feature
Development

Successfully merging this pull request may close these issues.

3 participants