Mailing List Archive

RFC0013 - how should overload `substr` interact with `nomethod`
I've started writing up the RFC0013 implementation of

use overload 'substr' => ...;

HAARG points out an unexpected design problem to do with the `nomethod`
callback:

https://github.com/Perl/perl5/pull/20735#issuecomment-1400848100

Anyone have any thoughts on this?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Mon, Jan 23, 2023 at 8:57 PM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> I've started writing up the RFC0013 implementation of
>
> use overload 'substr' => ...;
>
> HAARG points out an unexpected design problem to do with the `nomethod`
> callback:
>
> https://github.com/Perl/perl5/pull/20735#issuecomment-1400848100
>
> Anyone have any thoughts on this?

The problem is not limited to nomethod. Overloads in general have a
defined signature where each argument has a specific meaning, no
matter what is invoked.

1. The object, as the invocant.
2. The second argument to the op.
3. A swap parameter. For a binary op, if the first arg did not have an
appropriate overload, the invocant and next argument will be swapped
and this will be true.
4. If invoked as a nomethod fallback, the original overload that was attempted.
5. If using a bitwise op, and the "bitwise" feature is enabled, a true value.

The second argument and swap option are passed even for unary overloads.

Based on this pattern, the substr overload parameters of position and
length would need to be the 6th and 7th argument. This doesn't really
seem reasonable.
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On 2023-01-24 01:07, Graham Knop wrote:
> Based on this pattern, the substr overload parameters of position and
> length would need to be the 6th and 7th argument. This doesn't really
> seem reasonable.

There is also this variant:

substr EXPR,OFFSET,LENGTH,REPLACEMENT

In the ticket I suggested to start supporting some ref for the 4th
parameter, to extend the API.

-- Ruud
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Tue, Jan 24, 2023 at 1:07 AM Graham Knop <haarg@haarg.org> wrote:

> The problem is not limited to nomethod. Overloads in general have a
> defined signature where each argument has a specific meaning, no
> matter what is invoked.
>
> 1. The object, as the invocant.
> 2. The second argument to the op.
> 3. A swap parameter. For a binary op, if the first arg did not have an
> appropriate overload, the invocant and next argument will be swapped
> and this will be true.
> 4. If invoked as a nomethod fallback, the original overload that was
> attempted.
> 5. If using a bitwise op, and the "bitwise" feature is enabled, a true
> value.
>
> The second argument and swap option are passed even for unary overloads.
>
> Based on this pattern, the substr overload parameters of position and
> length would need to be the 6th and 7th argument. This doesn't really
> seem reasonable.
>

Barring Ruud's suggestion for adding a reference in the argument list,
would it be possible to get out of this via either of these?

1. use overloaded ...; (A new version of overload)
2. Find some way of signaling to overload to use different arguments (use
overload -version => 2, '""' => 'to_string', fallback => 1;).

The second one might be a nasty hack. The first one would allow a clean
reimplementation and maybe a nicer interface, though whether it would get
any traction is a different story.

--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Tue, 24 Jan 2023 01:07:23 +0100
Graham Knop <haarg@haarg.org> wrote:

> The problem is not limited to nomethod. Overloads in general have a
> defined signature where each argument has a specific meaning, no
> matter what is invoked.

Isn't that just somewhat coïncidental, because up until now we've only
had unary or binary operators in here. substr is the first thing which
breaks that pattern, having 3 (or 4) positional arguments to it, but
only being unary dispatch on the first of those. The second two (or
three with replacement) are just extra information that doesn't take
part in the dispatching decision.

> 1. The object, as the invocant.
> 2. The second argument to the op.
> 3. A swap parameter. For a binary op, if the first arg did not have an
> appropriate overload, the invocant and next argument will be swapped
> and this will be true.
> 4. If invoked as a nomethod fallback, the original overload that was
> attempted. 5. If using a bitwise op, and the "bitwise" feature is
> enabled, a true value.
>
> The second argument and swap option are passed even for unary
> overloads.
>
> Based on this pattern, the substr overload parameters of position and
> length would need to be the 6th and 7th argument. This doesn't really
> seem reasonable.

The whole situation feels slightly reminiscent of the trouble with
things like caller() and stat() [the latter of which is largely fixed
by File::stat]. Namely, that we have an API shape which is defined in
terms of a fairly ad-hoc list of positional values, and it becomes
difficult to extend the information provided by just giving more values.


If we were to start again from scratch, I'd suggest what we'd probably
come up with is an API shape wherein the first (non-invocant) value
passed in to any of the callbacks is an instance of some "overload
context" object, followed by all of the remaining arguments.

use overload
"+" => sub ($self, $ctx, $other) { ... }
"sin" => sub ($self, $ctx) { ... }
"substr" => sub ($self, $ctx, $pos, $len) { ... }

"nomethod" => sub ($self, $ctx, @args) { ... }
etc...;

Such a context object would then have some methods on it to get

$ctx->operator_name # or maybe something shorter
$ctx->is_swapped
$ctx->is_numerical
etc...

much easier to extend the available information later on by just adding
new methods to that context object. Since it's always just one
positional argument to any of the callbacks, it doesn't get in the way
of extra arguments later on.


Now of course, we don't live in that world. Currently. But I wonder if
we can somehow get there from here.

First (and most radical) idea: some sort of marker/version/indicator on
the `use overload` to say "Hey I'm using this fundamentally new and
totally different API shape".

use overload
newapi => 1, # deargod we need a better name here ;)

nomethod => sub ($self, $ctx, @args) { ... } # is now all fine

It'd allow newly-written code to work with this new structure, but it's
not the most version-friendly approach because overload.pm isn't
dual-life and no older versions would recognise this. So we'd be stuck
having to write code only for perl 5.38+ if we wanted to use this.

Perhaps it could be solved by a dual-life-capable "overload::v2" which
is shipped by newer perls and can be CPAN shimmed around older ones:

use overload::v2
nomethod => sub ($self, $ctx, @args) { ... };


Second idea: we could observe that currently most code that does look
up the operation name just treats it as a plain string. If this new
context object had stringification overloading on it, then the object
itself could now be passed in the position where currently a plain
string turns up, and most code should cope just fine:

use overload
nomethod => sub ($self, $other, $swapped, $opname) {
if($opname eq "+") { ... }
};

That'd at least let us pass this "extra information" object in to all
the callbacks, allowing e.g. the substr one to find its additional
arguments that way:

use overload
substr => sub ($self, $, $, $ctx) {
my $pos = $ctx->substr_pos;
my $len = $ctx->substr_len;
...
};

I don't know. That's kinda icky, and isn't very nice longer-term. It
feels like that's the "smallest reasonable step" solution to get us out
of where we are now, to permit this. But I think I would prefer a nicer
API shape as given in the "First idea", even if it's a harder step to
take from where we are.

Where we are now isn't a reasonable place to start from, so we
shouldn't feel too bad if it's a painful step to get from here to
somewhere more sensible.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Tue, 24 Jan 2023 17:48:40 +0100
Ovid <curtis.poe@gmail.com> wrote:

> 1. use overloaded ...; (A new version of overload)
> 2. Find some way of signaling to overload to use different
> arguments (use overload -version => 2, '""' => 'to_string', fallback
> => 1;).
>
> The second one might be a nasty hack. The first one would allow a
> clean reimplementation and maybe a nicer interface, though whether it
> would get any traction is a different story.

Ahyes, I was just suggesting basically that in my own reply just now. :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Tue, 24 Jan 2023 16:58:10 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Perhaps it could be solved by a dual-life-capable "overload::v2" which
> is shipped by newer perls and can be CPAN shimmed around older ones:
>
> use overload::v2
> nomethod => sub ($self, $ctx, @args) { ... };

Having discussed this more in the PSC meeting, this feels like probably
the best way forward actually.

Bikeshedding needs to happen on exactly what the module name should be,
but overall this feels best. A new module that can be shipped with core
perl but also live on CPAN dual-life for older perls. It would act as
a little shim around the calling-convention of the callbacks, adapting
them all to a newer better shape, whereby the arg shape is always of
that form:

($self, $ctx, @args)

where $ctx stores a standard "overloading context" object having some
methods to carry things like the op name and the swapped flag, and
@args contains just everything else that would have been visible as
perl-level arguments. So unops see nothing else there, binops see
$other, and new stuff like substr or whatever would see the other
values.

The context being an object with methods on it makes a much easier
place to attach other information in future, as new named methods can
easily be added to it.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2023-02-01 22:26:27 +0000]:

> On Tue, 24 Jan 2023 16:58:10 +0000
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > Perhaps it could be solved by a dual-life-capable "overload::v2" which
> > is shipped by newer perls and can be CPAN shimmed around older ones:
> >
> > use overload::v2
> > nomethod => sub ($self, $ctx, @args) { ... };
>
> Having discussed this more in the PSC meeting, this feels like probably
> the best way forward actually.
>
> Bikeshedding needs to happen on exactly what the module name should be,

We need to please stop using the term "bikeshedding" and just manage feedback
better. Most of us probably know the context of the original email,

http://phk.freebsd.dk/sagas/bikeshed/

I know the context in which it is often used, here, and elsewhere. And
frankly, I don't think it's appropriate in any sense because it's either
insulting or unproductive - a lot of times, both. Don't get me wrong,
I admire PHK's many contributions to OSS, but I don't admire this one
in the least.

Consider breaking down calls for feedback among the different groups so
they can be properly digested and valued for what they are. Internals folks,
application developers, golfers, testers, early adopters, etc will all have
valuable feedback. Better than doing it all at once and filtering based on
who seems to only care about the color of the "outhouse", which is a more
honest name.

Thank you, I hope my plea is well received and it might also improve the
situation, however so slightly, for getting more smart fellers around here
keeping up the plumbing (yanno that's connected to the outhouse).

Cheers,
Brett

> but overall this feels best. A new module that can be shipped with core
> perl but also live on CPAN dual-life for older perls. It would act as
> a little shim around the calling-convention of the callbacks, adapting
> them all to a newer better shape, whereby the arg shape is always of
> that form:
>
> ($self, $ctx, @args)
>
> where $ctx stores a standard "overloading context" object having some
> methods to carry things like the op name and the swapped flag, and
> @args contains just everything else that would have been visible as
> perl-level arguments. So unops see nothing else there, binops see
> $other, and new stuff like substr or whatever would see the other
> values.
>
> The context being an object with methods on it makes a much easier
> place to attach other information in future, as new named methods can
> easily be added to it.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Wed, 1 Feb 2023 22:26:27 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> > Perhaps it could be solved by a dual-life-capable "overload::v2"
> > which is shipped by newer perls and can be CPAN shimmed around
> > older ones:
> >
> > use overload::v2
> > nomethod => sub ($self, $ctx, @args) { ... };
>
> Having discussed this more in the PSC meeting, this feels like
> probably the best way forward actually.

Further discussed today and actually it feels like `overload::v2`
probably is the best name. It really emphasises that this is version 2
of the `overload` API, it's not a new different thing. We're bumping to
version 2 because the original API (which we can belatedly call v1) was
not shaped right to allow extension of arguments or other information
later on.

We *could* name this something else like `overload::better` or
whatever, but that doesn't convey the same meaning.

And while we're at it, `overload::v2` can fix a couple of other API
mistakes that were made in v1; for example setting `fallback` to true
by default, and also `join_uses_concat`. They'd still be available as
named keys to be opted out of if required, but it's imagined that most
uses will want them turned on most of the time.

[.[.As a side note: Additionally I observed that, if we did have some
sort of ability to allow multiple modules to be installed under the
same name but different major version numbers, then we could have
supported this as

use overload v2 ...

But trying to hack such a system into Perl at *this* late stage in
the game feels like a lot of effort, and also *waaay* too much effort
to be justified simply for getting a new overload API just so we can
add `substr` overloading. So that's a discussion we'll have to defer
for another day]]

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Fri, Feb 03, 2023 at 05:37:50PM +0000, Paul "LeoNerd" Evans wrote:
> > > Perhaps it could be solved by a dual-life-capable "overload::v2"
> > > which is shipped by newer perls and can be CPAN shimmed around
> > > older ones:
> > >
> > > use overload::v2
> > > nomethod => sub ($self, $ctx, @args) { ... };

Perhaps I'm not following closely enough, but I don't see how that solves
the major issues.

Question:

Consider an existing module which provides objects with string overloading
(it perhaps defines '""' and '.', and perhaps uses fallback and/or
nomethod_.

When code which supplies objects provided by that module to substr (or
join or whatever) is run on a newer perl (which supports now substr
overloading), will that code continue to run okay? Will Perl call the
correct string overload methods and/or nomethod() in a backwards
compatible manner, or will the code suddenly die because either it can't
find a 'substr' overload method, or it calls the nomethod method in a way
that expects that method to understand substr, but that module hasn't
been updated to make its nomethod handle substr, so it does the Wrong
Thing.




--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Fri, 3 Feb 2023 17:37:50 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> And while we're at it, `overload::v2` can fix a couple of other API
> mistakes that were made in v1; for example setting `fallback` to true
> by default, and also `join_uses_concat`. They'd still be available as
> named keys to be opted out of if required, but it's imagined that most
> uses will want them turned on most of the time.
>
> [.[.As a side note: Additionally I observed that, if we did have some
> sort of ability to allow multiple modules to be installed under the
> same name but different major version numbers, then we could have
> supported this as
>
> use overload v2 ...
>
> But trying to hack such a system into Perl at *this* late stage in
> the game feels like a lot of effort, and also *waaay* too much
> effort to be justified simply for getting a new overload API just so
> we can add `substr` overloading. So that's a discussion we'll have to
> defer for another day]]

Oh, but wait a second: We can.

We can't have two different `overload.pm` files on the filesystem, no.
That would be crazy. But we can have one file that contains both
versioned behaviours, and detect what version number someone requested
on their `use` line (for more detail on how, see below). So actually we
*can* support

use overload v2
substr => sub { ... };

Additionally the version number 2 of "overload" is available to us,
because right now core's overload.pm sets

our $VERSION = '1.36';

Perhaps this is the best way forward? Build that mechanism into core's
overload.pm, and then reshape it suitable for dual-life release on CPAN.

How do folks feel about that? Is it too subtle a thing for users of a
module, to have its behaviour change *simply* because of a different
version number appearing on its use line? I.e. explaining this
difference

use overload
nomethod => sub ($self, $other, $swapped, $mname) { ... };

vs

use overload v2
nomethod => sub ($self, $ctx, $other) { ... };

Version-dependent importing *is* a thing that is possible in Perl. Some
CPAN modules already do it; e.g. strictures [1]. Perhaps it's a thing
we want to make use of here, to get us moving forward on overload. And
in addition, keep it in mind as an API shape for whatever new
Exporter-type thing we might add to core later on. Certainly it can be
misused and create much user confusion - but the same can be said about
basically any Perl feature. If used properly, it could be a great tool
for extending features while maintaining backward compatibility.

[1]: https://metacpan.org/pod/strictures#VERSIONS

-----

### Further details on version detection

As part of a `use` statement, core perl invokes the `->import` method
and passes it the list of symbols. But before that, if you requested a
version it also invokes the `->VERSION` method, which is normally
implemented by UNIVERSAL. We can just hook that, call down to UNIVERSAL
first, then inspect the requested version ourselves:

package import_at_ver;

sub VERSION
{
UNIVERSAL::VERSION(@_);
my ($pkg, $ver) = @_;
...
}

What can we do at this time that's of any practical benefit though? One
simple thing we can do is store the requested version into the lexical
hints hash so `import` can see it (suitably normalized into a
'version' instance).

sub VERSION
{
UNIVERSAL::VERSION(@_);
my ($pkg, $ver) = @_;
$^H{"$pkg/VERSION"} = version->new($ver);
}

sub import
{
my ($pkg, @syms) = @_;
my $ver = delete $^H{"$pkg/VERSION"} // v1;
...

The upshot of doing all this is that we can easily now do something
different at import time, depending on the requested version of the
module.

For example we could go as far as to have two totally different
"import" methods in our module, invoked in the two cases:

sub import
{
my ($pkg, @syms) = @_;
my $ver = delete $^H{"$pkg/VERSION"} // v1;
if ( $ver lt v2.0 ) { $pkg->import_v1( @syms ); }
elsif( $ver lt v3.0 ) { $pkg->import_v2( @syms ); }
else { die "Unrecognised import version $ver for '$pkg'" }
}
...

This all works fine:

$ perl -I. -E 'use import_at_ver'
Importing import_at_ver v1 symbols <>

$ perl -I. -E 'use import_at_ver qw(foo)'
Importing import_at_ver v1 symbols <foo>

$ perl -I. -E 'use import_at_ver v2'
Importing import_at_ver v2 symbols <>

$ perl -I. -E 'use import_at_ver v2 qw(foo)'
Importing import_at_ver v2 symbols <foo>

Non v-string numbers of course are still supported:

$ perl -I. -E 'use import_at_ver 2.0'
Importing import_at_ver v2 symbols <>

$ perl -I. -E 'use import_at_ver 2.023'
Importing import_at_ver v2 symbols <>

Because this is all done with lexical hints at import time, there's no
problem with different users wanting different versions of this module;
or even different scopes of the *same* using module. It all works just
fine.

$ perl -I. -E '{ use import_at_ver v2 qw(foo) } { use import_at_ver qw(bar) }'
Importing import_at_ver v2 symbols <foo>
Importing import_at_ver v1 symbols <bar>


--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Sat, 4 Feb 2023 12:39:48 +0000
Dave Mitchell <davem@iabyn.com> wrote:

> Question:
>
> Consider an existing module which provides objects with string
> overloading (it perhaps defines '""' and '.', and perhaps uses
> fallback and/or nomethod_.
>
> When code which supplies objects provided by that module to substr (or
> join or whatever) is run on a newer perl (which supports now substr
> overloading), will that code continue to run okay? Will Perl call the
> correct string overload methods and/or nomethod() in a backwards
> compatible manner, or will the code suddenly die because either it
> can't find a 'substr' overload method,

In my current implementation, if there's no `substr` overload method it
just falls back on the previous behaviour of stringifying then applying
the plain PV-based core substr on the result.

> or it calls the nomethod
> method in a way that expects that method to understand substr, but
> that module hasn't been updated to make its nomethod handle substr,
> so it does the Wrong Thing.

That's where the version number comes in. We'd only invoke a
"substr nomethod" fallback if the overload'ing module said they were
using the v2 API, and thus were expecting to receive it.

In effect, it all means that if the overload-using string-like class
doesn't use overload's v2 API, everything behaves as if substr
overloading just did not exist. Much as it hasn't done in previous
perls.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Mon, Feb 13, 2023 at 10:44 AM Paul "LeoNerd" Evans <
leonerd@leonerd.org.uk> wrote:

> On Fri, 3 Feb 2023 17:37:50 +0000
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > And while we're at it, `overload::v2` can fix a couple of other API
> > mistakes that were made in v1; for example setting `fallback` to true
> > by default, and also `join_uses_concat`. They'd still be available as
> > named keys to be opted out of if required, but it's imagined that most
> > uses will want them turned on most of the time.
> >
> > [.[.As a side note: Additionally I observed that, if we did have some
> > sort of ability to allow multiple modules to be installed under the
> > same name but different major version numbers, then we could have
> > supported this as
> >
> > use overload v2 ...
> >
> > But trying to hack such a system into Perl at *this* late stage in
> > the game feels like a lot of effort, and also *waaay* too much
> > effort to be justified simply for getting a new overload API just so
> > we can add `substr` overloading. So that's a discussion we'll have to
> > defer for another day]]
>
> Oh, but wait a second: We can.
>
> We can't have two different `overload.pm` files on the filesystem, no.
> That would be crazy. But we can have one file that contains both
> versioned behaviours, and detect what version number someone requested
> on their `use` line (for more detail on how, see below). So actually we
> *can* support
>
> use overload v2
> substr => sub { ... };
>
> Additionally the version number 2 of "overload" is available to us,
> because right now core's overload.pm sets
>
> our $VERSION = '1.36';
>
> Perhaps this is the best way forward? Build that mechanism into core's
> overload.pm, and then reshape it suitable for dual-life release on CPAN.
>
> How do folks feel about that? Is it too subtle a thing for users of a
> module, to have its behaviour change *simply* because of a different
> version number appearing on its use line? I.e. explaining this
> difference
>
> use overload
> nomethod => sub ($self, $other, $swapped, $mname) { ... };
>
> vs
>
> use overload v2
> nomethod => sub ($self, $ctx, $other) { ... };
>
> Version-dependent importing *is* a thing that is possible in Perl. Some
> CPAN modules already do it; e.g. strictures [1]. Perhaps it's a thing
> we want to make use of here, to get us moving forward on overload. And
> in addition, keep it in mind as an API shape for whatever new
> Exporter-type thing we might add to core later on. Certainly it can be
> misused and create much user confusion - but the same can be said about
> basically any Perl feature. If used properly, it could be a great tool
> for extending features while maintaining backward compatibility.
>

You could have import arguments of `api => 2` or similar (shape borrowed
from FFI::Platypus) and have the exact same benefits without any
possibility of weird interactions or pigeonholing for future version
requirements. Old versions of overload of course don't recognize this
syntax but at least they would emit the warning: "overload arg 'api' is
invalid".

-Dan
Re: RFC0013 - how should overload `substr` interact with `nomethod` [ In reply to ]
On Mon, 13 Feb 2023 13:30:21 -0500
Dan Book <grinnz@gmail.com> wrote:

> You could have import arguments of `api => 2` or similar (shape
> borrowed from FFI::Platypus) and have the exact same benefits without
> any possibility of weird interactions or pigeonholing for future
> version requirements. Old versions of overload of course don't
> recognize this syntax but at least they would emit the warning:
> "overload arg 'api' is invalid".

Hmmm, I guess that's fair. In this case the subtle trick, while
possible, doesn't really buy much you couldn't beforehand. And as you
point out the previous version would complain about it anyway, so it's
probably simplest just to do `api => VER` indeed.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/