Proposal: Warning for Default Trait Implementations on Structs with Pointers

[tothambrus11]

I propose a new compiler warning to improve safety when working with structs that contain Pointer<T> or PointerToMutable<T> members.

Currently, if a struct with a pointer member conforms to core traits like Copyable, Equatable, Movable, Deinitializable, Equatable using the default synthesized implementation, the compiler doesn't raise any flags. This can be problematic, as the default behavior (e.g., bitwise copying or comparison of the pointer) is often not the intended semantics, potentially leading to bugs. Forgetting to provide a custom implementation is an easy mistake to make.

To address this, the compiler should emit a warning in these cases.

For situations where the default behavior is intentional (such as when creating a wrapper around a pointer), this warning could be silenced with specific annotations:

• @ReferenceIsPartOfValue on the pointer member: indicates that the pointer's identity is what we consider contributing to the value of this struct.
• @ValueIsAReference on the struct itself: indicating that warnings like this should be displayed on usage of this type. Pointer<T> and PointerToMutable<T> would need to have this added, and also any reference-valued wrapper built around them.

This change would make pointer-related code safer by default, requiring developers to be explicit about their intent instead.

What are your thoughts on this proposal?

[kyouko-taiga]

I don't think it is a good idea.

(1) The issue of determining whether or not a particular field is part of a type's notional value is not as pervasive as an issue in Hylo than it is in traditional OO languages, thanks to the absence of references. The rule is simply that the value of fields are part of a type's notional value unless stated otherwise.

(2) This proposal worsen user experience for the legit use cases where equality (and other value properties) are meant to be defined in terms of identities stored in a type as opposed to the identified object, for performance. One would have to explicitly implement Equatable to silence the warning even if their type was obviously meant to use pointer equality.

(3) I don't think the annotation makes sense. Many types can be used as "references", including just Int. By the logic of this proposal I would have to annotate Int with @ValueIsReference in the off-chance someone decides to store a collection of indices into an array.

(4) Using the annotation should become viral because Array<Pointer<Int>> should technically also be considered "dangerous" under the proposal's logic. So the type system would have to carry this information through all generic instantiations, which sounds costly and tricky for separate compilation.

(5) It seems clear to me that pointers won't appear in standard, every-day code. Therefore the mere presence of a member of type Pointer<T> in a structure should be enough to deserve extra scrutiny in code reviews.