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

Make Tuple and NamedTuples .types to return tuples of metaclasses #4962

Merged
merged 4 commits into from
Sep 15, 2017

Conversation

bcardiff
Copy link
Member

Fixes #4737

Tuple#types return a tuple value now. Instead of a tuple type.
An analogous NamedTuple#types is added.
Since this methods depends only on the generic argument they can be class methods also/instead(?).

There is a small duplication hard to track in the compiler specs.
I am not sure if the specs should have some conditional like the one that was added before

@oprypin
Copy link
Member

oprypin commented Sep 13, 2017

Tuple#types seems redundant
especially if you consider for an analogy that sizeof(obj) does not work

@bcardiff
Copy link
Member Author

Another slightly inconsistency I found is that in macro interpreter given a generic type one can ask type_vars (that result in an ArrayLiteral, src-1 & src-2) and named_args (that result in an NamedTupleLiteral, src-3). The later matches NamedTuple.types, but the former maybe should return a TupleLiteral instead of an ArrayLiteral

@bcardiff
Copy link
Member Author

I would prefer to remove the Tuple and NamedTuple types instance methods and leave only the class methods. 👍 / 👎 ? At most is a tuple.class.types vs tuple.types.

@asterite
Copy link
Member

@bcardiff I don't think the semantic/codegen specs need to change, these don't require the prelude. They are testing that T is available as a tuple.

@bcardiff
Copy link
Member Author

Ok @asterite I will rollback that but change slightly the compiled code in spec to avoid confusion with the stdlib implementation.

@bcardiff
Copy link
Member Author

New shot with cleaned commit history. The commit c654908 is not actually regarding the NamedTuples.types method but is a missing piece to align the behavior of named tuples and tuples metaclasses. While doing it I enforce some checks in the semantic and codegen since the TupleIndexer ast node handling was assuming a tuple metaclass as the default case.

#
# ```
# tuple_type = typeof({a: 1, b: "hello", c: 'x'})
# tuple_type.types # => {a: Int32, b: String, c: Char}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add another example accessing types from the instance?

tuple = {a: 1, b: "hello", c: 'x'}
tuple.class.types # => {a: Int32, b: String, c: Char}

That will avoid some people trying to do tuple.types by mistake.

😁

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure. I will just change to your example. It's actually like the specs your suggestion.

@bcardiff bcardiff merged commit 4b1e14f into crystal-lang:master Sep 15, 2017
@bcardiff bcardiff added this to the Next milestone Sep 15, 2017
@bcardiff bcardiff deleted the fix/tuple-types branch October 3, 2017 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants