From @bbkr

Named params print required types​:

17​:33 bbkr​: r​: sub MAIN (Int :$x!) {...}
17​:33 camelia​: rakudo-{moar,jvm} c2a57e​: OUTPUT«Usage​:␤ /tmp/tmpfile -x=<Int> ␤»

However positional types does not​:

17​:33 bbkr​: r​: sub MAIN (Int $x!) {...}
17​:33 camelia​: rakudo-{moar,jvm} c2a57e​: OUTPUT«Usage​:␤ /tmp/tmpfile <x> ␤»

I think this is bug because type is more important than irrelevant variable name.
Expected output is​: "Usage​:␤ /tmp/tmpfile <Int>"

From @pmichaud

On Tue May 26 08​:38​:30 2015, bbkr@​post.pl wrote​:

I think this is bug because type is more important than irrelevant
variable name.
Expected output is​: "Usage​:␤ /tmp/tmpfile <Int>"

In this case, the variable name is "irrelevant" primarily because the programmer chose an irrelevant name. A clearer case for the current behavior comes from

  sub MAIN (Int $count!) { ... }

which produces a more useful "Usage​:␤ /tmp/tmpfile <count>" message.

Or consider a grep-like replacement​:

  sub MAIN ($pattern!, @​*files) { ... }

that produces "Usage​:␤ /tmp/tmpfile <pattern> [<files> ...]".

In the original report, an argument can be made that the programmer ought to have made the program more useful by writing

  sub MAIN (Int $integer) { ... }

which outputs "Usage​:␤ /tmp/SJk_VxNAxM <integer>".

I'm inclined to reject this ticket, but will leave it open for further discussion.

Pm

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

From @bbkr

In the original report, an argument can be made that the programmer ought to have made the program more useful by writing

sub MAIN (Int $integer) { ... }

What if there are two integer params? MAIN (Int $integer1, Int $integer2) looks bad and subroutine body may be hard to understand.
We already have typed variable and choosing variable name to duplicate type name just to display this information to caller is redundant.

Despite that I found another inconsistency in positional params - anonymous one still display types​:

$ perl6 -e 'sub MAIN (Int, Str) { ... }'
Usage​:
-e '...' <Int> <Str>

Maybe more consistent way of displaying types would be​:
"--age=<Int> --name=<Str>" for named
"<Int>age <Str>name" for positional with variable name
"<Int> <Str>" for anonymous positional
?

From @bbkr

BTW​: whatever decision for this ticket will be, also there is inconsistency between usage text and how Perl 6 display types​:

$ perl6 -e 'Int.WHAT.say'
(Int)

So it should be displayed as --age=(Int) instead of --age=<Int>.

From @bbkr

In the original report, an argument can be made that the programmer ought to have made the program more useful by writing

sub MAIN (Int $integer) { ... }

What if there are two integer params? MAIN (Int $integer1, Int $integer2) looks bad and subroutine body may be hard to understand.
We already have typed variable and choosing variable name to duplicate type name just to display this information to caller is redundant.

Despite that I found another inconsistency in positional params - anonymous one still display types​:

$ perl6 -e 'sub MAIN (Int, Str) { ... }'
Usage​:
  -e '...' <Int> <Str>

Maybe more consistent way of displaying types would be "--age=<Int> --name=<Str>" for named and "<Int>age <Str>name" for named positionals and "<Int> <Str>" for anonymous positionals?

On 26 May 2015, at 20​:01, Patrick R. Michaud via RT <perl6-bugs-followup@​perl.org> wrote​:

On Tue May 26 08​:38​:30 2015, bbkr@​post.pl wrote​:

I think this is bug because type is more important than irrelevant
variable name.
Expected output is​: "Usage​:␤ /tmp/tmpfile <Int>"

In this case, the variable name is "irrelevant" primarily because the programmer chose an irrelevant name. A clearer case for the current behavior comes from

sub MAIN (Int $count!) { ... }

which produces a more useful "Usage​:␤ /tmp/tmpfile <count>" message.

Or consider a grep-like replacement​:

sub MAIN ($pattern!, @​*files) { ... }

that produces "Usage​:␤ /tmp/tmpfile <pattern> [<files> ...]".

In the original report, an argument can be made that the programmer ought to have made the program more useful by writing

sub MAIN (Int $integer) { ... }

which outputs "Usage​:␤ /tmp/SJk_VxNAxM <integer>".

I'm inclined to reject this ticket, but will leave it open for further discussion.

Pm

From @sjn

I think this bug can be closed.

Here's my reasoning. For me, a major point with the auto-generated usage text is that it helps the developer of the program see the importance of picking good variable names. If a dev chooses to name them $integer1 and $integer2 (which are obviously horrible variable names because they tell nothing about what they will be used for), then the generated usage text *should* looks stupid. Garbage in, garbage out.

In the same way, if the name of the variable doesn't give an indication of the type (e.g. $age is a number), then the error is still with the developer and not the language.

This is a non-issue, and the ticket should be closed. :)

- Salve (who is looking through all tickets related to MAIN)

Wed, 27 May 2015 06​:11​:13 -0700 skrev bbkr@​post.pl​:

In the original report, an argument can be made that the programmer
ought to have made the program more useful by writing

sub MAIN (Int $integer) { ... }

What if there are two integer params? MAIN (Int $integer1, Int
$integer2) looks bad and subroutine body may be hard to understand.
We already have typed variable and choosing variable name to duplicate
type name just to display this information to caller is redundant.

Despite that I found another inconsistency in positional params -
anonymous one still display types​:

$ perl6 -e 'sub MAIN (Int, Str) { ... }'
Usage​:
-e '...' <Int> <Str>

Maybe more consistent way of displaying types would be "--age=<Int>
--name=<Str>" for named and "<Int>age <Str>name" for named positionals
and "<Int> <Str>" for anonymous positionals?

On 26 May 2015, at 20​:01, Patrick R. Michaud via RT <perl6-bugs-
followup@​perl.org> wrote​:

On Tue May 26 08​:38​:30 2015, bbkr@​post.pl wrote​:

I think this is bug because type is more important than irrelevant
variable name.
Expected output is​: "Usage​:␤ /tmp/tmpfile <Int>"

In this case, the variable name is "irrelevant" primarily because the
programmer chose an irrelevant name. A clearer case for the current
behavior comes from

sub MAIN (Int $count!) { ... }

which produces a more useful "Usage​:␤ /tmp/tmpfile <count>"
message.

Or consider a grep-like replacement​:

sub MAIN ($pattern!, @​*files) { ... }

that produces "Usage​:␤ /tmp/tmpfile <pattern> [<files> ...]".

In the original report, an argument can be made that the programmer
ought to have made the program more useful by writing

sub MAIN (Int $integer) { ... }

which outputs "Usage​:␤ /tmp/SJk_VxNAxM <integer>".

I'm inclined to reject this ticket, but will leave it open for
further discussion.

Pm

From @zoffixznet

On Sat, 30 Sep 2017 12​:45​:09 -0700, sjn-perlbug@​pvv.org wrote​:

I think this bug can be closed.

Agreed. Rejecting.

I see little reason to muddy up the Usage even more with type information,
where you're mostly limited to Int/Str types anyway, and variable name
helps know which to use.

The type info is helpful with named args, because without types present,
it'd be harder to know whether they are Bool flags.

also there is
inconsistency between usage text and how Perl 6 display types​:

$ perl6 -e 'Int.WHAT.say'
(Int)

So it should be displayed as --age=(Int) instead of --age=<Int>.

Don't see much consistency relevance between USAGE and the behaviour of the
.gist method on type objects. Personally, I use `Int.^name.say` to display
types...

I found another inconsistency in positional params -
anonymous one still display types​:

Seems reasonable to me. Lacking a variable name, there's little else
to display in its place.

Cheers,
ZZ

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