When you write 1.0 == 1.0 in Tyra, you get a compile error.
error[E0305]: Float does not satisfy the Eq ability
--> src/main.ty:3:8
|
3 | if a == 1.0
| ^^ Float has no Eq
|
= help: use float.eq(a, 1.0) for IEEE 754 equality,
or float.approx_eq(a, b, epsilon: 1e-9) for tolerance comparison
This is intentional. Here's why.
The NaN problem
IEEE 754 — the floating-point standard every language uses — defines that NaN != NaN. Always. No exceptions.
# Python
x = float('nan')
x == x # False
// Go
x := math.NaN()
x == x // false
This rule exists for numerical computing reasons (NaN propagation semantics), but it breaks one of the most fundamental assumptions in programming: any value equals itself.
In every language that gives Float a standard equality operator, you have a class of values called reflexivity-breaking values: things where a == a is false. Most programmers don't think about this until they hit a bug.
What breaks when Float has Eq
Structural equality on compound types
Tyra has value types — immutable record types that get structural equality: two Points are equal if all their fields are equal.
value Point
x: Float
y: Float
end
If Float had Eq, Tyra would auto-derive Eq for Point. But then:
let p = Point(x: 0.0 / 0.0, y: 1.0) # x is NaN
p == p # What should this return?
IEEE 754 says NaN != NaN, so field-by-field comparison gives false.
Structural equality says two identical objects are equal, so it should be true.
These two invariants cannot both hold. Pick one and you're lying to the programmer about the other.
Hash maps and sets
In Python and JavaScript, using a float as a dictionary key works until it doesn't:
d = {}
d[float('nan')] = 1
d[float('nan')] = 2
len(d) # 2 — two different NaN keys!
This happens because hash(nan) == hash(nan) but nan != nan, so two NaN keys are considered distinct. The HashMap contract (a == b implies hash(a) == hash(b)) is violated silently.
In Tyra, Map<Float, V> is a compile error. The bug class doesn't exist.
The three ways to handle this
Every language with a static type system faces this problem. The mainstream options:
Option 1: IEEE 754 semantics (most languages)
Float == Float works, NaN != NaN. Reflexivity breaks for NaN values.
This is what C, Java, JavaScript, Python, and Go do. It's pragmatic and familiar, but it leaks IEEE 754 semantics into the equality abstraction. Bugs involving NaN are notoriously hard to trace.
Option 2: Two-tier equality (Rust)
Rust splits the concept: PartialEq means "might not be reflexive" (Float qualifies), Eq means "always reflexive" (Float does not).
// Rust: Point derives PartialEq but NOT Eq
#[derive(PartialEq)]
struct Point { x: f64, y: f64 }
This is honest and precise, but it adds complexity. PartialEq vs Eq is one of Rust's most confusing distinctions for beginners — two equality traits, two sets of bounds in generics, two different things to explain.
Option 3: No Eq for Float (Tyra)
Float simply does not satisfy Eq. The operator == is only available for types that provably satisfy reflexivity.
Explicit comparison functions are available:
import float
float.eq(a, b) # IEEE 754: NaN != NaN, 0.0 == -0.0
float.approx_eq(a, b, epsilon: 1e-9) # tolerance comparison
float.is_nan(a) # explicit NaN check
Why this is the right tradeoff for Tyra
Tyra's target domain is web backends, CLI tools, and business applications — not scientific computing or graphics engines. In that domain:
- Money should be
Int(cents), neverFloat - JSON numbers that need exact comparison are usually integers
- The legitimate use cases for float equality are rare and should be explicit
The error message points you to the right function. The type system forces you to think about what kind of float comparison you actually want — not just reach for == and hope NaN never shows up.
What this enables: AI-friendly design
One of Tyra's goals is to be a language where LLMs generate correct code on first try, without debugging cycles. Float equality traps are a significant source of subtle bugs in LLM-generated code. The model writes a == b because that's the pattern it learned from Python and JavaScript. The Tyra compiler rejects it and explains the alternative.
In our benchmark (100 tasks, Claude generating code from the language spec), Tyra achieves an 88.7% mean pass rate across 3 seeds. This exceeds Go's existing seed-1 point estimate (81%), though the two figures use different methodologies so a same-condition comparison is still pending. Design choices like this one — where the type system catches a common bug class before the test runner does — are consistent with that result.
The ability system
For those unfamiliar with Tyra: abilities are Tyra's type classes. They work like Rust traits or Haskell type classes, but the name distinguishes them from Tyra's trait keyword, which is the mechanism for interface polymorphism — a separate concept.
The four core abilities are Eq, Hash, Ord, and Debug. Auto-derivation works by structural inspection: a value or data type gets Eq automatically if and only if all its fields satisfy Eq. Since Float doesn't satisfy Eq, no type containing a Float field gets Eq for free.
This propagation rule is intentionally simple and consistent: no exceptions, no special cases. One rule covers everything.
The tradeoff is real
I'm not going to pretend there's no cost. Writing float.approx_eq(result, expected, epsilon: 1e-9) in a test is more verbose than result == expected. If you're writing numerical algorithms, the absence of == on floats is genuinely inconvenient.
But the alternative is a category of bugs that are hard to find, hard to name, and hard to explain — to a reviewer, a type checker, or an LLM. Tyra trades some verbosity to eliminate the bug class entirely.
If you're building the next numerical solver or game engine, Tyra is probably not your language. If you're building a web API or a CLI tool, float equality probably isn't something you need — and if you do need it, the error message tells you exactly what to use instead.
Tyra is an open-source, Ruby-inspired language that compiles to native binaries via LLVM.
Source: github.com/tyra-lang/tyra — feedback welcome.