From @dakkar

Given this code​::

  {
  class Foo { has $.x }

  multi sub infix​:<eqv>(Foo $a, Foo $b) {
  say "won't get called";
  $a.x eqv $b.x
  }
  }

  multi sub infix​:<eqv>(Foo $a, Foo $b) {
  say "will get called";
  $a.x eqv $b.x
  }

  my @​a = Foo.new(​:x(1));
  my @​b = Foo.new(​:x(1));

  say @​a[0] eqv @​b[0];
  say @​a eqv @​b;

the output is​::

  will get called
  True
  False

because​:

- the first ``eqv`` definition is not visible to any of the calls
- the second ``eqv`` definition is not visible to the
  ``infix​:<eqv>(@​a,@​b)`` in the setting

This means that​:

- ``eqv``s defined in other packages are never used
- adding a ``eqv`` for users' types is not very useful, since they
  won't be called most of the time

Should there be some mechanism like ``ACCEPTS`` to make ``eqv`` more
useful?

Should there be a mechanism to add ``multi`` candidates dynamically?
 
--
  Dakkar - <Mobilis in mobile>
  GPG public key fingerprint = A071 E618 DD2C 5901 9574
  6FE2 40EA 9883 7519 3F88
  key id = 0x75193F88

You have only to mumble a few words in church to get married and few
words in your sleep to get divorced.

From @jnthn

On Sat Sep 05 07​:47​:24 2015, dakkar wrote​:

Given this code​::

{
class Foo { has $.x }

multi sub infix&#8203;:\<eqv>\(Foo $a, Foo $b\) \{
  say "won't get called";
  $a\.x eqv $b\.x
\}

}

multi sub infix​:<eqv>(Foo $a, Foo $b) {
say "will get called";
$a.x eqv $b.x
}

my @​a = Foo.new(​:x(1));
my @​b = Foo.new(​:x(1));

say @​a[0] eqv @​b[0];
say @​a eqv @​b;

the output is​::

will get called
True
False

because​:

- the first ``eqv`` definition is not visible to any of the calls
- the second ``eqv`` definition is not visible to the
``infix​:<eqv>(@​a,@​b)`` in the setting

This is correct; multis are lexically scoped.

This means that​:

- ``eqv``s defined in other packages are never used
Well, they are in the lexical scope of the package.

- adding a ``eqv`` for users' types is not very useful, since they
won't be called most of the time

Typically you'll be writing such types in a module; adding "is export" to the eqv multi candidates you declare will export them, and then they'll be available to anyone importing your type. And if you're in a single file, you can still write them inside of a package and then "import" that package to get them into scope.

Should there be some mechanism like ``ACCEPTS`` to make ``eqv`` more
useful?

No, given then you'd be able to apply this argument to every other operator in the language you might consider overloading.

Should there be a mechanism to add ``multi`` candidates dynamically?

We have to know the list of multi-candidates at CHECK time; since export/import happen at BEGIN time, then that's enough "static dynamism" for this case.

Hope this helps,

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'rejected'