Do tuples need a shared non-`Object` superclass?

[lrhn]

The proposal for tuples have a Record class which acts as a common supertype of tuple types.

Whether that is necessary or desirable depends on perspective and features.

The main reason for separate types to have a shared supertype is either having a shared interface or other shared affordances.
For example function types have a common supertype Function which abstracts over their ability to be called (they have a "dynamic call" member), and people are asking for a supertype of enums, which have a shared int get index; interface member.

So, the question is whether tuples should have any shared functionality, and if not, whether they should have a supertype anyway, for good measure.

The proposal suggests that the Record class have methods which reflect on the tuple. Those work on all tuples, and only on tuples, and therefore need an argument type of Record.
I would prefer to not add such functions outside of dart:mirrors, and then they would be part of a RecordMirror, not something which works on the reified tuple itself. If they exist outside of mirrors, the functions could also take any object as argument, and treat non-tupes as if they were one-tuples containing the value (I also argue that there should be no one-tuples because the product type T^1 is just T, so that would be consistent).

There is no other shared functionality between tuples, those two reflective functions are the only ones which work on tuples independently of the tuple "width"/"arity"/"structure". There is no shared interface members between (int, int) and ({int x}), so without those two method, there is no advantage in knowing that something is a tuple, because you still don't know which tuple structure it is (and there is a countably infinite number of those if you try to do an exhaustive search). You're better off casting to dynamic if you want to explore the members of an arbitrary tuple, than by trying to cast to a tuple type.

If there are no empty tuples (or even no singleton-tuples), the Record type also feels incomplete (to me). It's true that it contains all tuples, but with that view, maybe a single object is a one-tuple, so why is Object not a subtype of Record?

Still, people like to have categories and be able to express those categories in code. Saying that a variable is a Record r; is documentation that is statically and dynamically enforced (whereas Object tuple; is just text, no enforcement).

(Betteridge's law says no.)

[eernstg]

class C<X extends Record> {...} could enforce the property that class C has a type argument which is a tuple type, and that might be useful from a conceptual point of view (it outlines how C should be understood) even if it doesn't make much difference technically.

For the shared properties, maybe the dynamic type of a Record could reveal the structure (as much as it must already, for a boxed value of that type). This could be offered to developers as instance getters int get numberOfPositionalFields.

This won't allow for the same level of introspection as the record proposal's positionalFields and namedFields, but it would allow a similar functionality at a lower level if a record r with 3 (or more ;-) positional fields would make r is (Object?, Object?, Object?) true.

We could also consider a getter Set<Symbol> get namedFields, but that's less promising: The named fields could already be accessed using a dynamic invocation, and the ability to get a set of symbols at run time won't help much.

[munificent]

I would prefer to not add such functions outside of dart:mirrors, and then they would be part of a RecordMirror, not something which works on the reified tuple itself.

Even if we do that, I still think they should have a more precise type that they accept beyond just Object, so that callers can better catch mistakes attempting to pass non-record types to it.

If they exist outside of mirrors, the functions could also take any object as argument, and treat non-tupes as if they were one-tuples containing the value (I also argue that there should be no one-tuples because the product type T^1 is just T, so that would be consistent).

Records as I've proposed them aren't really like strict product types. That model falls down when you consider that a record with a single named field is still clearly distinct from the field's value. (This is part of the reason I call them "records" and not "tuples".) I think it's better to think of them as immutable heterogeneous collections. From that perspective, there's no reason not to support a one-positional-field record.

There is no shared interface members between (int, int) and ({int x}), so without those two method, there is no advantage in knowing that something is a tuple, because you still don't know which tuple structure it is (and there is a countably infinite number of those if you try to do an exhaustive search).

Record types may not have any members in common now, but that doesn't mean that users might not want to define extensions shared across all record types. I admit the body of that extension doesn't have a ton of useful affordances on this, but I think users could and likely will still find them useful to define.

Basically, I think providing Record as a tag interface is relatively harmless and potentially useful, so I lean towards just doing it.

[lrhn]

I would prefer to not add such functions outside of dart:mirrors, and then they would be part of a RecordMirror, not something which works on the reified tuple itself.

Even if we do that, I still think they should have a more precise type that they accept beyond just Object, so that callers can better catch mistakes attempting to pass non-record types to it.

Nobody would be passing tuples into anything. You'd do reflect(myTuple) and the result would be a TupleMirror instead of (or in addition to) an InstanceMirror. You can then check that it is a tuple mirror, and use the tuple specific methods.
Mirrors work by reflecting, then working on the mirrors, not providing introspection directly on the reified objects.

[munificent]

In 98341cd, I removed the reflective methods on Record. This means that it's currently an empty interface with no members, so we could remove it if we wanted to. However, I've left it in for now because I suspect it might be somewhat useful as a tag interface.

There are places where users write functions that accept one of a handful of known types. In the absence of overloading, they usually just accept Object and then type test each of the allowed types in the body. I expect that code like that will sometimes happen where all of the allowed types are record types, and having a Record supertype gives users at least a marginally more precise type to use.

[natebosch]

Is there risk in experimenting, or even shipping, without the Record type? Can we wait until we see the case where it is useful to provide it?

[munificent]

Is there risk in experimenting, or even shipping, without the Record type? Can we wait until we see the case where it is useful to provide it?

Yes, I think we could do that. We essentially did the same thing with Enum, which was added as the supertype of enums in 2.14. But... I think the fact that we ended up adding Enum is also a hint that we will end up wanting a supertype for record types too.

I think it's fairly harmless to add it eagerly, and I do think it's useful and something users will occasionally want. Also, all of our other structural types have a corresponding supertype: Enum for enum types, Function for function types.

[lrhn]

Out existing supertypes have funcitonality. Enum has int get index; and Function has a magic call. Record likely will not have any interface members. (It might have abstract == and hashCode declaration for documentation purposes.)

The interface methods are not the only reason these types to exist. I use Function just as a reminder that whatever is stored in this polymorphic function, at least I know it's a function of some sort. It's not necessary, but it is slightly helping readability. I'd expect people to want Record for the same reason.

For example, if we rewrite noSuchMethod/Invocation and Function.apply to use records for the arguments (which we should eventually), the type of Function.apply would be dynamic apply(Function function, Record arguments);, and that's actually the best we can do.
(Well, unless we can use record types to abstract over function type parameter list, like make Function generic as Function<A extends Record, R>, so that int Function(int, int) extends Function<(int, int), int>, then we can do R apply<A, R>(Function<A, R> function, A arguments)!)

[munificent]

I use Function just as a reminder that whatever is stored in this polymorphic function, at least I know it's a function of some sort. It's not necessary, but it is slightly helping readability. I'd expect people to want Record for the same reason.

Yes, I think this is the primary motivation for having a Record type even if it's (currently) just an empty interface. Since we don't have overloading or polymorphism over record arity, I'm certain users will sometimes write functions like:

/// Does some useful thing with the given [tuple], which should be a record
/// with only positional fields up to arity ten.
doStuffWithTuple(tuple) {
  switch (tuple) {
    case (f1, f2): ...
    case (f1, f2, f3): ...
    case (f1, f2, f3, f4): ...
    ...
  }
}

Having a Record supertype gives users a type that is at least marginally more precise than Object for that tuple parameter's type.

I'm going to leave Record in the proposal and close this, but feel free to re-open if any of you disagree.