You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only way to create a record value is a record literal. If you want some other function to create a record for you, you need to wrap that up as a function, (int v1, String v2) => (v1, v2).
I think it could be useful to allow record types to be considered as having a const unnamed generative constructor, which can be torn off. Or called, if that's considered useful.
That would allow more easily creating a function which creates a record from arguments in the same order.
It may also be useful for using record types in places where a constructor is expected (potentially #2967), and if we add any future features which work on types with constructors, records would fit in (say if we ever allow calling constructor through type parameters, or let them have static interfaces).
Allowing a constructor to be torn off, from a specific record type, should not change the analysis of which record shapes are used by a program, although it would probably consider the shape used, even if the constructor is never called. (Unless the tear-off itself can be tree-shaken.)
It's not trivial to access the constructor directly, since you can't write (int, int).new (it's not in the grammar).
The workaround would likely be having a typedef typeof<T> = T; and do typeof<(int, int)>.new. That's a reasonable enough workaround, and the type-alias could be useful in other ways too.
Calling it as, say, a super-constructor of an inline class would work directly.
(And if you have a typedef Tuple2<T1, T1> = (T1, T2); you can do Tuple2(v1, v2) and get the normal type inference applied.)
The text was updated successfully, but these errors were encountered:
If you want some other function to create a record for you, you need to wrap that up as a function, (int v1, String v2) => (v1, v2).
Is that so bad?
If we ever allow spreading records into argument lists, I could see us also offering some syntax for the opposite: capturing a parameter list as a record. If we did that (let's say the syntax is foo), then it would be:
I think it would be nice to have this feature. Currently instantiating big records is a bit annoying, as a typo in a field name, or accidentally passing a wrong type (int? instead of a int) somewhere makes IDE highlight the entire (...) expression instead of the wrong part. So the solution is to write out the instantiating function manually (#2528), but nobody got time for that.
The only way to create a record value is a record literal. If you want some other function to create a record for you, you need to wrap that up as a function,
(int v1, String v2) => (v1, v2)
.I think it could be useful to allow record types to be considered as having a
const
unnamed generative constructor, which can be torn off. Or called, if that's considered useful.That would allow more easily creating a function which creates a record from arguments in the same order.
It may also be useful for using record types in places where a constructor is expected (potentially #2967), and if we add any future features which work on types with constructors, records would fit in (say if we ever allow calling constructor through type parameters, or let them have static interfaces).
Allowing a constructor to be torn off, from a specific record type, should not change the analysis of which record shapes are used by a program, although it would probably consider the shape used, even if the constructor is never called. (Unless the tear-off itself can be tree-shaken.)
It's not trivial to access the constructor directly, since you can't write
(int, int).new
(it's not in the grammar).The workaround would likely be having a
typedef typeof<T> = T;
and dotypeof<(int, int)>.new
. That's a reasonable enough workaround, and the type-alias could be useful in other ways too.Calling it as, say, a super-constructor of an inline class would work directly.
(And if you have a
typedef Tuple2<T1, T1> = (T1, T2);
you can doTuple2(v1, v2)
and get the normal type inference applied.)The text was updated successfully, but these errors were encountered: