From @ilmari

Or to put another way​: attributes with 'is required' should not need an
initialiser even if the type has a :D smiley, and a :D type without an
initialiser should imply 'is required'.

The first and second examples below should be equivalent.

  > class { has Int​:D $.count }.new(count => 42)
  ===SORRY!=== Error while compiling <unknown file>
  Variable definition of type Int​:D requires an initializer
  at <unknown file>​:1

  > class { has Int​:D $.count is required = Int }.new(count => 42)
  <anon>.new(count => 42)

And the error message should probably be this​:

  > class { has Int $.count is required }.new()
  The attribute '$!count' is required, but you did not provide a value for it.
  in block <unit> at <unknown file>​:1

Rather than this​:

  > class { has Int​:D $.count is required = Int }.new()
  Type check failed in assignment to $!count; expected Int​:D but got Int
  in block <unit> at <unknown file>​:1

--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen

From @FROGGS

I don't think that we should mix two concepts here.

The type constraint of an attribute just tells us what types/subsets are allowed to be contained in the attribute.

That an attribute should be passed when instantiating an object (maybe passed but undef?) is another story. And this has not much to do with definedness of an attribute.

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

From @zoffixznet

On Thu, 08 Oct 2015 03​:12​:02 -0700, ilmari wrote​:

Or to put another way​: attributes with 'is required' should not need
an
initialiser even if the type has a :D smiley, and a :D type without an
initialiser should imply 'is required'.

The first and second examples below should be equivalent.

class { has Int​:D $.count }.new(count => 42)
===SORRY!=== Error while compiling <unknown file>
Variable definition of type Int​:D requires an initializer
at <unknown file>​:1

class { has Int​:D $.count is required = Int }.new(count => 42)
<anon>.new(count => 42)

And the error message should probably be this​:

class { has Int $.count is required }.new()
The attribute '$!count' is required, but you did not provide a value
for it.
in block <unit> at <unknown file>​:1

Rather than this​:

class { has Int​:D $.count is required = Int }.new()
Type check failed in assignment to $!count; expected Int​:D but got Int
in block <unit> at <unknown file>​:1

On Thu, 08 Oct 2015 07​:34​:43 -0700, FROGGS.de wrote​:

I don't think that we should mix two concepts here.

Agreed. Especially since `is default` trait can be used, making the cases where
implied `is required` trait would make sense even more narrow.

It's possible the user intended to "accept only definite values" without realizing
the default default of the attribute would not pass the type constraint. Silently
making the attribute required would just add more to the confusion.

Rather than this​:

class { has Int​:D $.count is required = Int }.new()
Type check failed in assignment to $!count; expected Int​:D but got Int
in block <unit> at <unknown file>​:1

Exactly that (required + default) should actually throw, the same as it does with
parameters in routines. I opened a separate Issue for that​:
rakudo/rakudo#1426

Without the default, the error is (and was, when issue was opened) the same for :D and :_ types

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