Something unexpected happened, once we added const generics to the 0.2 beta.
We discovered that by enabling passing functions as generic parameters, we also effectively enabled concepts, a way to specify constraints on parameters, without making them implement any traits.
For example, let's say we already have a Ship struct and a calcDamage function:
struct Ship {
strength int;
}
func calcDamage(ship &Ship, target &Ship) int {
ship.strength - target.strength
}Now we want a battle function, which can take any type as long as it has a calcDamage function:
func battle<T>(attacker T, defender T)
where func calcDamage(&T, &T)int
{
damage = calcDamage(attacker, defender);
// ... other logic
return damage;
}There it is! That where func calcDamage(&T, &T)int specifies that there must be a calcDamage function that takes in two &Ts.
The only mainstream language today which can accomplish something like this is C++, with its requires requires clause: 0
template<typename T>
requires requires(T a) { { calcDamage(&a, &a) } -> std::same_as<int>; }
int battle(T* attacker, T* defender) {
int damage = calcDamage(attacker, defender);
// ... other logic
return damage;
}As you can see, Vale makes it wonderfully easy to use this approach.
We already use it thoroughly in our standard library. For example, in optutils.vale, we have a function Opt<T>.clone that's only enabled if T also has a clone method:
func clone<T>(self &Opt<T>) Opt<T>
where func clone(&T)T {
...
}This can be a lot easier, compared to previous approaches.
For example, in Java or C# or Rust, if we had a pre-existing Ship and calcDamage function, we would have to make an interface (or trait) to describe the bounds and then require all callers to to make their arguments extend that interface (or make an impl, in Rust's case) for every type that they want to supply.
Here's an example in Rust:
// Let's say we had a pre-existing function and a struct...
struct Ship {
strength: i32
}
fn calcDamage(ship: &Ship, target: &Ship) -> i32 {
return ship.strength - target.strength;
}
// And we want a function that can take any type.
// We'll need a trait for the functions we want to call on it.
trait Fireable {
fn calcDamage(&self, target: &Self) -> i32;
}
fn battle<T: Fireable>(attacker: &T, defender: &T) -> i32 {
let damage = attacker.calcDamage(defender);
// ... other logic
return damage
}
// And the caller must make an `impl` for every type we want to feed into `battle`
impl Fireable for Ship {
fn calcDamage(&self, target: &Self) -> i32 {
// (Can optionally inline this, if this is the only usage.)
return calcDamage(&self, &target);
}
}If we can't modify the existing type (such as if it's defined by a third-party library) we sometimes need to make a wrapper class (sometimes known as a typeclass or a newtype) which can implement the required interface.
After using this for a few weeks, I had a shocking realization: this is similar in spirit to how we did things in C!
This snippet in Vale...
struct Ship {
strength int;
}
func calcDamage(ship &Ship, target &Ship) int {
ship.strength - target.strength
}
func battle<T>(attacker T, defender T)
where func calcDamage(&T, &T)int
{
damage = calcDamage(attacker, defender);
// ... other logic
return damage;
}
...would be this in C:
struct Ship {
int strength;
};
int calcDamage(Ship* ship, target &Ship) {
return ship.strength - target.strength;
}
typedef int (*Fire)(void*, void*);
int battle(
void* attacker,
void* defender,
Fire calcDamage) {
int damage =
calcDamage(attacker, defender);
// ... other logic
return damage;
}
The only real difference is that Vale passes the calcDamage function in at compile-time, and C passes it in at run-time via a function pointer. Aside from that, these approaches are the same.
Note how neither requires that calcDamage be a method of the type, they can be free functions. I think this is a much cleaner approach, that allows us to decouple the type from the functions we use on it.
Thanks for reading, we hope you enjoyed this article!