Emulating named tuple elements

[tothambrus11]

I played around with the new frontend and experimented with emulating named tuple members. I assumed I would use a tag struct that gives me a unique type, and my goal was to arrive at a tuple initializer expression that requires writing the correct tag before corresponding to each part.

When using a similar technique in libraries, we would need to export the name tag, and when conflict arises, qualify it with our module name like MyModule.x.

/// Wrapper type for a named tuple element.
public struct Tagged<Name, Type> {
  public var value: Type

  public memberwise init
  
  // No argument labels
  public static fun create<N where N == Name>(value: sink Type) -> Tagged<Name, Type> {
    Tagged<Name, Type>(value: value)
  }
}

public given<Name, Type is Deinitializable>
  Tagged<Name, Type> is Deinitializable {  
  }

public given<Name, Type is Movable> 
  Tagged<Name, Type> is Movable {
  }

public struct x { } // tag type for x element
public struct y { } // tag type for y element


type Vec2 = {Tagged<x, Int>, Tagged<y, Int>}

fun make<Name, Type>(value: sink Type) -> Tagged<Name, Type> {
  Tagged<Name, Type>.create(value)
}

// let v: Vec2 = (.create<x>(1), .create<y>(2)) // no context to resolve implicit qualification
// let part: Tagged<x, Int> = .create<x>(1) // no coercion from '#!' to 'Tagged<x, Int>'
// let part: Tagged<x, Int> = .create<x,_>(1) // no coercion from '#!' to 'Tagged<x, Int>'

// let v: Vec2 = (make<x>(1), make<y>(2)) // 'make' takes 2 compile-time argument(s); found 1
let v: Vec2 = (make<x,_>(1), make<y,_>(2))  // this works, though not the nicest syntax

I remembered that there was a reason why we didn't add named tuples as a language feature, but didn't exactly remember the reason. We can use this thread to record any of those previous concerns & more.

Side note: Some of my commented out naive trials feel they ought to work. Can't we use an implicit base qualification inside a tuple expression when its type is ascribed?

[RishabhRD]

It made me remember NamedType C++ library. Maybe a typealias can help for improving readability (Not sure as I didn't play much with the new frontend). A sample example from above library:

template<typename Function>
using Comparator = NamedType<Function, struct ComparatorTag>;

[kyouko-taiga]

This is a code smell:

public static fun create<N where N == Name>(value: sink Type) -> Tagged<Name, Type> {
  Tagged<Name, Type>(value: value)
}

Specifically, equality constraints involving a concrete type (i.e., not introduced by the signature itself) are often fishy and I would probably warn them in a linter. They just make the type signature more complicated by adding new implicit parameters.

Typer will be more compliant if you write this:

struct Tagged<N, T> {
  public init(v: sink T) {}
}

struct X {}
struct Y {}
type V2 = {Tagged<X, Int>, Tagged<Y, Int>}

let x: {Tagged<X, Int>, Tagged<Y, Int>} = (.new(1), .new(2))

Side note: Some of my commented out naive trials feel they ought to work. Can't we use an implicit base qualification inside a tuple expression when its type is ascribed?

I agree. Given that my above example works I suspect the typer just doesn't dealias the ascription when it visit the RHS of the declaration. That should be an easy fix.

[tothambrus11]

It might be extra work for the type system, but now you are no longer required to explicitly annotate each value with a label on initialization. That's something that some extra surface syntax rules could fix though, so we don't really need the extra create function.

[kyouko-taiga]

I remembered that there was a reason why we didn't add named tuples as a language feature, but didn't exactly remember the reason.

The reason is that tuple labels would make it much more difficult to soundly express tuple consing in the type system, which is useful for writing this in the standard library:

public given <T is Deinitializable, U is Deinitializable> => {T, ...U} is Deinitializable {}

In English: given a type T that is deinitializable and a tuple U that is deinitializable, the tuple prepending T to U is deinitializable.

It is possible to express labels as types but that is not trivial.