What generated methods should structs provide?

[leafpetersen]

The struct proposal (#2360) specifies that a number of methods are automatically generated for structs. The core set, which I think are relatively uncontroversial, are equality, hashCode, copyWith method, and a default constructor are generated. In addition, I proposed a debugToString method to support debug printing in a way that is not tied to object interpolation and hence is less likely to accidentally cause type information to be retained unnecessarily (this is a common source of code size bloat in large applications).

The debugToString specification is only loosely thought through, @rakudrama had suggestions around using a more structured format.

It may also be desirable to include other generated methods, e.g. some way of providing general coding and decoding members (cc @jakemac53 )

This issue is for discussing the general question of what generated members to provide, and with what types and semantics.

It may prove useful to file sub-issues to discuss specific proposals, which can be linked in here.

[leafpetersen]

cc @mit-mit @lrhn @eernstg @munificent @stereotype441 @natebosch @jakemac53 @rakudrama @srujzs @sigmundch @rileyporter @mraleph

[lrhn]

I wouldn't start adding toDebugString() (which is what I'd name it) unless we can also add it to other objects. If we can add it to Object, I'd be delighted, but just having it on struct objects seems too arbitrary.

(A more generally useful functionality would be a List<Object?> get fields which provides the value of all the fields of the object. That's still reflection, and not something I actually want.)

[mmcdon20]

Why not have toString() implement this behavior instead of adding an additional toDebugString()?

Other languages with a similar feature use this approach, for example:

Data classes in Kotlin:

data class Coordinate(val x: Int, val y: Int)
fun main() {
    println(Coordinate(5, 10)) // Coordinate(x=5, y=10)
}

Case classes in Scala:

case class Coordinate(x: Int, y: Int)
println(Coordinate(5, 10)) // Coordinate(5,10)

Structs in Swift:

struct Coordinate {
  let x: Int
  let y: Int
}
print(Coordinate(x: 5, y: 10)) // Coordinate(x: 5, y: 10)

Records in Java:

record Coordinate(int x, int y) {}

public class Example {
    public static void main(String args[]) {
        System.out.println(new Coordinate(5, 10)); // Coordinate[x=5, y=10]
    }
}

Records in C#:

using System;

record Coordinate(int X, int Y);

public class Program
{
    public static void Main()
    {
        Console.WriteLine(new Coordinate(5, 10)); // Coordinate { X = 5, Y = 10 }
    }
}

[rrousselGit]

About the generated copyWith, will it support struct.copyWith(property: null)?

[lrhn]

@rrousselGit As described, it will support setting a property to null.

As with constructors, this method cannot be generated as a strict de-sugaring, since the ability to detect whether or not an argument has been passed is not available in Dart.

[rrousselGit]

Nice! I saw that line but wasn't sure about the implications

I suppose two remaining useful "functions" would be a fromJson/toJson.
But I suppose we're unlikely to get those?

[lrhn]

I definitely do not expect toJson/fromJson because there is no general way to go from any value to or from JSON, and the fields of a struct can contain any value.

[mraleph]

I think we should consider splitting this into its own feature, I suggest to look at this as an interface auto derivation feature which works for structs and classes alike, e.g.

// dart.core

/// If you implement this interface compiler would derive implementations of
/// its methods in the class. 
abstract class Equatable {
  int get hashCode;

  bool operator == (Object other);
}

/// If you implement this interface compiler would derive implementations of
/// its methods in the class. 
abstract class Encodable {
  Map<String, dynamic> toJson();
}

/// If you implement this interface compiler would derive implementations of
/// its methods in the class. 
abstract class Encodable {
  void encodeTo(Encoder e);
}

abstract class Encoder {
  void addProperty(String key, Object? value);
  void addEncodable(String key, Object? value);
}


class X implements Equatable, Encodable {
  final int x;
  final int y;
  final Z z;  // class Z implements Encodable

  // derived by the compiler
  bool operator == (Object other) {
    return other is X && this.x == other.x && this.y == other.y && this.z == other.z;
  }

  // derived by the compiler
  void encodeTo(Encoder e) {
    e.addProperty('x', x);
    e.addProperty('y', y);
    e.addEncodable('z', z);
  }
}

This is a bit similar to macros but bakes in the support in the language.

I think one of the open questions here is deep vs shallow equality for things like lists and other collections and how to control derivation of that.

[Levi-Lesches]

Wouldn't methods that iterate over fields of the class be better handled by macros? Instead of inheriting a magically generated method, you'd apply the macro yourself to show that the code is being generated. Then you could also choose between the default (ie, most popular or built-in) implementation or something else (a macro on pub.dev or your own). The logic for generating these methods would be more transparent, as anyone could inspect the macro's source code or the generated augmentation files for themselves.