Make Tuple and NamedTuples .types to return tuples of metaclasses #4962
Conversation
|
|
|
Another slightly inconsistency I found is that in macro interpreter given a generic type one can ask |
|
I would prefer to remove the Tuple and NamedTuple types instance methods and leave only the class methods. 👍 / 👎 ? At most is a |
|
@bcardiff I don't think the semantic/codegen specs need to change, these don't require the prelude. They are testing that |
|
Ok @asterite I will rollback that but change slightly the compiled code in spec to avoid confusion with the stdlib implementation. |
bcardiff
force-pushed
the
fix/tuple-types
branch
from
a82d046
to
c654908
Compare
|
New shot with cleaned commit history. The commit c654908 is not actually regarding the |
src/named_tuple.cr
Outdated
| # | ||
| # ``` | ||
| # tuple_type = typeof({a: 1, b: "hello", c: 'x'}) | ||
| # tuple_type.types # => {a: Int32, b: String, c: Char} |
There was a problem hiding this comment.
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.
😁
There was a problem hiding this comment.
Sure. I will just change to your example. It's actually like the specs your suggestion.
Remove unusable Tuple#types
mimic behavior from tuple
bcardiff
force-pushed
the
fix/tuple-types
branch
from
c654908
to
4df8ead
Compare
Fixes #4737
Tuple#typesreturn a tuple value now. Instead of a tuple type.An analogous
NamedTuple#typesis 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