[perl6/specs] 1903a5: Bring parameter semantics in line with reality.

2015-12-21 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 1903a509e3ac4fefbd769673e6a26eb84fee31fa
  
https://github.com/perl6/specs/commit/1903a509e3ac4fefbd769673e6a26eb84fee31fa
  Author: jnthn 
  Date:   2015-12-18 (Fri, 18 Dec 2015)

  Changed paths:
M S06-routines.pod

  Log Message:
  ---
  Bring parameter semantics in line with reality.

Besides being what is implemented, these also allow for more/better
optimization (we already have optimizations that depend on them; if
we took the previous semantics, things like spesh would be unable to
rely supposedly readonly parameters never changing under them due to
their being aliases).




Type constraint for named parameters, and questions about 6.c backwards compat

2015-12-21 Thread Rob Hoelz
Hello Perl 6 users and developers!

I asked this in #perl6, but I wasn't getting a response there, so I
figured I would try here.

In the following code:

> use v6;
>
> class C {
> has Str $!dist-id;
>
> submethod BUILD(:$!dist-id) {}
> }
>
> my ( $build ) = C.can('BUILD');
> say $build.signature.params[1].type; # prints Any, should it be Str?

If I try to pass a non-Str to C.new, I will get a type check failure,
as the value cannot go into $!dist-id, so that functionality works.
However, as in the example, if I am inspecting the signature, the type
constraint is Any.  Should we change this so that it's Str instead?

This brings up another question: how backwards compatible will 6.c be?
Let's say that the above behavior occurs with 6.c, and someone brings up
the Any vs Str question after 6.c is released.  Since someone could
technically depend on introspection of the signature returning Any in
this case, would we be hesitant to change the behavior?

Thanks,
Rob