Maybe due to your conciseness and my basic Enlgish I have doubts on the second part of your post: I'd like you to expand a bit

> Depending on $ret is a mistake, its a sad part of that api

The usage of checking $ret (explicit or implicit) aka the return value of the GetOptions call is a well established behaviour. What to do better? Should I wrap into an eval block? Iirc I tried but no $@ was set in case of errors.

> Sub::Getopt::Long is a wrong namespace prefix

I never understood how English people set the position of arguments: I'm Latin! Getopt::Long::Sub sounds better? or you are saying that the Getopt::Long part is wrong? Something like Sub::Long::Arguments or what?

> Work on more use case first. And i don't mean mocks

The above code is a quick hack: I just covered what it came to my mind in the meanwhile, but it seems these example covering most use cases.

The assumption is that you finally get your arguments inside a hash (given its flaxibility this should cover most needs, imho). So you would call the futurible method from my unborn module in this way:

        # dest                   {defaults}            [template]     
+ original @_

        my %opts = longargs( {len => 1, wid => 2}, [qw( len=i wid=i )]
+, @_ );
[download]

Which use cases are you imagining?

Thanks for looking

L*

Since this idea relates to functions and their parameters, something similar to Function::Parameters (although that's obviously taken)?

return value of the GetOptions call is a well established behaviour.

heh. Almost everything is a fail, sometimes even success. Even correct usage had bugs. Ive observed best use is ignore.

conciseness

its a virtue of mobile device :) virtual keyboards are a pain , esp with thumbs

I never understood how English people set the position of arguments: I'm Latin!

cpan is first come first serve. And hierarchy goes left to right. Sub:: is wrong prefix .

Getopt::Long::Sub sounds better?

Yes but all it says its based on getopt which we from the hierarchy already :) Vanity name Getopt::Long::Discipulus?

Sub::Long::Arguments or what?

Why 3 branches? Want 3 words why not Sub::GetoptLong ? Choices are hard even with guidelines Re^2: Naming a module that handles SIP2 (library protocol stopwords) Re: RFC: Automatic logger module.

...Which use cases are you imagining?

one where longargs is nicer or not identical to GetOptionsFromArray , but i struggle