Implement `@auto("==")` on types by tjpalmer · Pull Request #581 · temperlang/temper

tjpalmer · 2026-10-09T00:10:55Z

Support on types but not on individual methods in this pr
Support classes and sealed interface hierarchies
Validate against unsupported things
Don't generate an == if one already exists
Always use the name eq for generated methods in this pr
Add docs and a release note (even though we don't have one yet for @operator, I don't think)

Signed-off-by: Tom <tom@temper.systems>

tjpalmer · 2026-10-09T16:20:52Z

 private val vZero = Value(0, TInt)

-internal fun dotHelperForOperator(member: Member): DotHelper {
+fun dotHelperForOperator(member: Member): DotHelper {


I wanted access.

tjpalmer · 2026-10-09T16:57:18Z

+import lang.temper.value.vVisibilitySymbol
+import lang.temper.value.vWordSymbol
+import lang.temper.value.valueContained
+import lang.temper.value.void


I love having a semi-lock file of imports in every file. So fun.

tjpalmer · 2026-10-09T16:57:53Z

+    fun addAutosIfWanted() {
+        reifiedType ?: return
+        // First check our own auto keys.
+        val autoKeys = typeDecl?.autoKeys() ?: listOf()


This abstracts the idea of there possibly being more than one, although this pr doesn't allow for that.

tjpalmer · 2026-10-09T16:58:54Z

+            }
+        }
+        // Also check the parents' auto keys, just in case.
+        addAutoEqForSuperSealedIfWanted(autoKeys)


Realized probably best to skip this if we had one above, but it's rare that someone would label both, and we eventually dodge duplicate == anyway, so maybe ok.

tjpalmer · 2026-10-09T17:01:02Z

+        eqBuiltinName.builtinKey in autoKeys && return
+        val typeShape = reifiedType!!.type2.definition as? TypeShape ?: return
+        // We care about this type only if it's concrete or sealed.
+        typeShape.abstractness == Abstractness.Concrete || typeShape.decl()?.isSealed() == true || return


Again, this case is for when there ain't an @auto("=="), so it's ok to skip. We'll separately check each type we do add == to for seeing if it has only class or sealed subtypes, so if there's a mismatch there, it's handled elsewhere.

tjpalmer · 2026-10-09T18:02:48Z

+    "Auto method not allowed with unsealed subtype(s): Sneaky!",
+    "Auto method not support for interface that's not sealed!",
+    "Auto method cannot support multiple supertype(s): Root1, Root2!",
+    "Type WhichToUse must implement eq from Root1.  Maybe add `public eq(other: Root1): Boolean`!"


One reason I kept this test in generate code stage instead of just define was so I could see this later stage errors such as this one.

tjpalmer · 2026-10-09T18:03:53Z

+```log
+Some are twins: true
+All are twins: false
+```


As I comment, this isn't testing backends so much as just testing that the code gen works anywhere.

We still should make passes to generate idiomatic operator methods in backends, though. Testing those would be a lot in backend tests.

tjpalmer · 2026-10-09T18:04:34Z

+    @auto("==")
+    sealed interface High {
+      toString(): String;
+    }


Above is the only @auto.

tjpalmer · 2026-10-09T18:04:49Z

+Low2(to be) == Low2(to be): true
+Low1(11) == Low3: false
+Low3 == Low3: true
+```


But all the varieties seem to work fine.

tjpalmer · 2026-10-09T18:05:31Z

    override fun hashCode() = stateVector.hashCode()

    companion object {
+        operator fun invoke(string: String) = Value(string, TString)


Maybe should have added this long ago. I used it in the new frontend tree gen.

Signed-off-by: Tom <tom@temper.systems>

tjpalmer · 2026-10-09T19:26:00Z

+});
+do {};
+void;
+Maybe extends AnyValue;


No pure virtual ==/eq for Maybe because it has an unsealed subtype. Maybe should just generate one anyway? I do give an error message for it, in any case.

mikesamuel · 2026-10-12T19:13:57Z


+<!-- snippet: builtin/@auto -->
+
+<a name="builtin&#45;&#64;auto" class="snippet-anchor-name"></a>


Love these docs

mikesamuel · 2026-10-12T19:15:59Z

+The *\@auto* decorator currently applies to a class or sealed interface,
+indicating that the specified operator should be automatically implemented
+for this type. In the future, it might be possible to specify on an
+individual method for a specific operator.


We had talked about a number of ways to get more fine-grained control.

Do you need to specify auto on the method or would you specify it on the class and then provide a stub method?

@auto("==") export class C(...) { @operator("==") public equivalent(other: C): Boolean; // pure virtual, so needs an implementation }

We had talked about a number of ways to get more fine-grained control.

Do you need to specify auto on the method or would you specify it on the class and then provide a stub method?

I guess either could provide a name, yeah. I could see arguments either way.

mikesamuel · 2026-10-12T19:17:06Z

+than class or sealed interface descendents. Inheriting `@auto("==")` from
+multiple sealed ancestor interface branches is also an error. Further, if a
+manual `@operator("==")` method exists for a type, no automatic
+implementation is injected.


Could we extend this to sealed interfaces with unsealed interface descendants that have a manual @operator("==") method?

mikesamuel · 2026-10-12T19:17:44Z

 }

+@Suppress("SameParameterValue")
 private fun errorTree(tree: Tree, leftIndex: Int, rightIndex: Int): CallTree =


mikesamuel · 2026-10-12T19:20:39Z

-    if (illegalSuperTypes.isEmpty()) {
+    if (illegalSuperTypes.isNotEmpty()) {
        (typeShape as MutableTypeShape).superTypes.removeAll(illegalSuperTypes)
    }


This does make more sense.

I'm guessing this is part of an attempt to make sure later passes don't have to deal with super-type cycles.

That's not something people often write.

mikesamuel · 2026-10-12T19:21:21Z

+export class HasOwn extends Maybe {
+  @operator("==")
+  public eq(other: Maybe): Boolean {
+    // No equality here!


tjpalmer added 18 commits October 2, 2026 15:57

Explore auto eq decoration

3c47df5

Signed-off-by: Tom <tom@temper.systems>

Explore more

3d20da3

Signed-off-by: Tom <tom@temper.systems>

Work on auto eq

687e5d2

Signed-off-by: Tom <tom@temper.systems>

Maybe get all but body done

24658fc

Signed-off-by: Tom <tom@temper.systems>

Maybe make valid logic

6d47ea9

Signed-off-by: Tom <tom@temper.systems>

Use last expression directly

95028ee

Signed-off-by: Tom <tom@temper.systems>

Update backend test; verify auto eq in action

6fdedb6

Signed-off-by: Tom <tom@temper.systems>

Work on sealed interfaces

c2109e6

Signed-off-by: Tom <tom@temper.systems>

Check types for autocast; make abstract abstract

41ae232

Signed-off-by: Tom <tom@temper.systems>

Don't cast something we don't use

1c4e3be

Signed-off-by: Tom <tom@temper.systems>

Test and fix auto eq across sealed hierarchies

364b19b

Signed-off-by: Tom <tom@temper.systems>

Move things around and document

0f4fdda

Signed-off-by: Tom <tom@temper.systems>

Check only concrete properties

c76f02b

Signed-off-by: Tom <tom@temper.systems>

Add missed symbols

d7aa73f

Signed-off-by: Tom <tom@temper.systems>

Move to gen code stage test

112df4a

Signed-off-by: Tom <tom@temper.systems>

Add error cases & checking; clean some extra

2d749eb

Signed-off-by: Tom <tom@temper.systems>

Don't auto == if there already is one

384fd93

Signed-off-by: Tom <tom@temper.systems>

Fix lint; update docs; add release note

2fee8b1

Signed-off-by: Tom <tom@temper.systems>

tjpalmer commented Oct 9, 2026

View reviewed changes

Remove old commented code

4ac2a6d

Signed-off-by: Tom <tom@temper.systems>

tjpalmer commented Oct 9, 2026

View reviewed changes

tjpalmer marked this pull request as ready for review October 9, 2026 21:02

tjpalmer mentioned this pull request Oct 10, 2026

Rust hidden sealed subs #617

Merged

mikesamuel approved these changes Oct 12, 2026

View reviewed changes

tjpalmer merged commit bc75d83 into main Oct 12, 2026
2 checks passed

tjpalmer deleted the auto-eq branch October 12, 2026 20:39


		<!-- snippet: builtin/@auto -->

		<a name="builtin-@auto" class="snippet-anchor-name"></a>

Conversation

tjpalmer commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tjpalmer commented Oct 9, 2026 •

edited

Loading