[perl #126291] [BUG] :D on attrs and vars fails with a defined default value

[via RT]

# New Ticket Created by  Larry Wall 
# Please include the string:  [perl #126291]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=126291 >


22:28 < TimToady> m: say  class { has Int:D $.foo is default(0) }.new
22:29 <+camelia> rakudo-moar 472ea0: OUTPUT«===SORRY!=== Error while
compiling /tmp/WV7JjqRYN7␤Variable definition of type Int:D requires an
 initializer␤at /tmp/WV7JjqRYN7:1␤-->   class { has
Int:D $.foo is default(0) ⏏}.new␤expecting any of:␤
 constraint␤»
22:29 < TimToady> I don't think that one should require an initializer
22:29 -!- coetry [~al...@c-50-171-35-243.hsd1.tx.comcast.net] has quit
[Quit: Lost terminal]
22:29 -!- allen [~al...@c-50-171-35-243.hsd1.tx.comcast.net] has quit
[Quit: Lost terminal]
22:30 < TimToady> m: my Int:D $x is default(0);
22:30 <+camelia> rakudo-moar 472ea0: OUTPUT«===SORRY!=== Error while
compiling /tmp/p5BBLy48x8␤Default value '0' will never bind to a
 parameter of type Int:D␤at /tmp/p5BBLy48x8:1␤--> my
Int:D $x is default(0)⏏;␤expecting any of:␤constraint␤»
22:30 < TimToady> say wot?
22:31 < TimToady> is that one bug or two?
22:32 < TimToady> m: my Int:D @array is default(0); @array[0] = Nil;
22:32 <+camelia> rakudo-moar 472ea0: OUTPUT«===SORRY!=== Error while
compiling /tmp/MpVmByHAQM␤Default value '0' will never bind to a
 parameter of type Array[Int:D]␤at
/tmp/MpVmByHAQM:1␤--> my Int:D @array is default(0)⏏; @array[0] =
Nil;␤expecting
 any of:␤co…»
22:33 < TimToady> two and a half?

[perl #101448] [BUG] No error on assigning a type object to a :D-constrained container in Rakudo

[Tobias Leich via RT]

Added tests:
https://github.com/perl6/roast/commit/fca109de6c
https://github.com/perl6/roast/commit/6e66b7a18d

Closing ticket.

[perl #126283] invocants default to :D ?

[via RT]

# New Ticket Created by  Elizabeth Mattijsen 
# Please include the string:  [perl #126283]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=126283 >


[12:14:07]  hmmm...
[12:14:34]  S06:1633 states: "In standard Perl 6, C is 
generally assumed to mean C, except for invocants, where the default is 
C."
[12:14:54]  I don't think we've actually implemented it this way at 
the moment?
[12:15:17]  m: class A { method foo { dd self } }; A.foo
[12:15:17]  <+camelia>  rakudo-moar c47145: OUTPUT«A␤»
[12:15:39]  according to S06:1633, that should have been an error ? 
  
[12:15:44]   lizmat: Indeed. Another little thing to decide before 
Christmas.
[12:16:09]   lizmat: I think the problem has always been that it 
makes it harder to write `new` methods
[12:16:11]  should I ticket this, or is it on the list somewhere 
already
[12:16:18]   You can ticket it
[12:16:39]  will do
[12:16:43]   The resolution may well end up being we change S06, but 
we should decide on it one way or the other.
[12:16:54]  yup, indeed  :-)

[perl #118069] [BUG] 'proto' should imply 'multi' on all subsequent routines of that name in Rakudo

[jn...@jnthn.net via RT]

On Mon May 20 10:55:06 2013, masak wrote:
>  r: proto sub a($) {*}; sub a(Int $x) { "yay" }
>  rakudo 8d2ec9: OUTPUT«===SORRY!===␤Redeclaration of routine
> a [...]
>  shouldn't that work? from syn: ". A proto also adds an
> implicit multi to all routines of the same short name within its
> scope, unless they have an explicit modifier"
> * masak submits rakudobug for that
>  I think that's already (long) known
>  yes, but I don't find it in RT.
>  submitting Justin Case, and then we can merge if someone finds
> it.

After some discussion, we decided to remove this from the design:

https://github.com/perl6/specs/commit/8ee967d2fa3464bffd640c8d5443c3dad1c8fec6

I've also removed the fudged tests linked to this ticket.

delegation

[mt1957]

Hi,

According to synopsis 12 I could defer methods to methods in another object.
The case in which one can map some name into another didn't work out.
*
**
**class A {**
**  method say-i (Int $i ) { say "I: $i"; }**
**}**
**
**class B {**
**  has A $.n handles { :x };**
**
**  submethod BUILD { $!n .= new; }**
**}**
**
**my B $b .= new;**
**$b.x(30);**
*

Error is
Method 'x' not found for invocant of class 'A'

OK, then I misunderstood it but when flipping the key value map in that 
particular line like so


*  has A $.n handles { :say-i };*

Error is now
Method 'x' not found for invocant of class 'B'

Removing brackets from the first try works
*  has A $.n handles :x;**
**
*As well as
*  has A $.n handles (:x);**
*
Conclusion is that curly brackets for Hash does not work while Pair's do.
Hashes aren't tested either. See|S12-attributes/delegation.t| lines 
|65–80| 
 



Greetings,
Marcel

[perl #126284] --> Int:D allowed but not checked correctly

[via RT]

# New Ticket Created by  Elizabeth Mattijsen 
# Please include the string:  [perl #126284]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=126284 >


[14:56:02]  m: sub a(--> Int:D) { Int }; a   # jnthn, is this 
supposed to die or not ?
[14:56:03]  <+camelia>  rakudo-moar dafcfe: ( no output )
[14:56:48]  jnthn: perhaps a compile time NYI for --> Foo:D ?
[15:00:14]   lizmat: Either we should fix it or disallow it
[15:00:48]  jnthn: will ticket it, ok?
[15:00:59]   +1

[perl6/specs] 8ee967: Remove language on proto auto-multi-ing routines.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 8ee967d2fa3464bffd640c8d5443c3dad1c8fec6
  
https://github.com/perl6/specs/commit/8ee967d2fa3464bffd640c8d5443c3dad1c8fec6
  Author: jnthn 
  Date:   2015-10-07 (Wed, 07 Oct 2015)

  Changed paths:
M S06-routines.pod

  Log Message:
  ---
  Remove language on proto auto-multi-ing routines.

Discussion: http://irclog.perlgeek.de/perl6/2015-10-06#i_11327412

Re: [perl #125762] [BUG] parameterisation has higher priority than postcircumfix:<[ ]> even on non-parameterizable types

[Lloyd Fournier]

Makes sense. I went with TypeName{'arg'} and TypeName instead of
TypeName['arg'] which is actually better in some ways. I wanted it to look
like Type::Tiny a bit but I guess that's what inbuilt types are for :)

On Wed, Oct 7, 2015 at 2:53 AM, jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Thu Aug 06 06:18:57 2015, lloyd.fo...@gmail.com wrote:
> > Context: I am trying to make a fun syntax where Class[@args] is an alias
> > for Class.new(@args)
> >
> > -
> > class C {};
> > sub postcircumfix:<[ ]>(C:U $c, Str $arg){ say 'win' };
> > my $c = C;
> > $c['test']; #-> win
> > C['test'];  #!> C cannot be parameterized
> >
> > --
>
> The syntax TypeName[...] is syntactically a type parameterization, by
> design. If you really want to force interpretation as an array indexing,
> it'd have to be written as:
>
> C.['test']; #-> win
>
> > I also tried:
> > --
> > role R { method parameterize(|) { say $*d; } };
> > class C {};
> > BEGIN { C.HOW does R };
> > my $*d = 'win';
> > C[my $a = 'test']; #-> win
> > C['test']#!> Dynamic variable $*d not found
> >
> > --
> > But I can't use dynamic variables because if it's called with a compile
> > time variable it runs .parameterize at compile time only.
> >
> Yes, and we're allowed to form parametric types at compile time whenever
> we know we have the parameters available (and if we can't do that, we have
> a lot of problems; for one it's the very mechanism that allows you to
> `does` a parametric role on a class declaration!) A parameterize method
> that isn't prepared to be called at compile time is buggy.
>
> > I tentatively suggest that at least one of these is a bug as they
> together
> > prevent you using [] on a type to callback to something using $*dynamic
> > variables consistently.
>
> Both behaviors are as intended. In general, anything of the form
> ` ` should be considered a special form. It's a
> pity we have to overload bracketing chars, but sadly ASCII is a bit
> limiting!
>
> Thanks,
>
> Jonathan
>
>