Aaron wrote:
> > sub foo (@args) -> rettype
>
> Hmm... I would have expected "is" to come in here:
>
> sub foo (@args) is IO::Handle
It would have to be:
sub foo (@args) is type(IO::Handle)
or something, I think. Unless Larry decides that every class/module
name is implicitly also the name of a trait that confers that type on
a referent.
Personally I suspect he may prefer to stick with "type-before-name":
my Dog $spot;
sub Dog hot {...}
rather than:
my $spot is Dog;
sub hot is Dog {...}
since using class/module names as auto-traits could lead to many unexpected
clashes in the traits namespace.
> > my $bar -> int;
>
> Hmm... This, I think is very different. Now you're getting into
> casting, and I fear a Perl6 that has casting. Next, we'll have to
> start considering the various types of casting that C++ provides
> (static, dynamic, etc).
No, this is nothing to do with casting. It's merely an alternative syntax for:
my int $bar;
> Did you think of -> as forcing the "my" expression to return a certain
> type or to say that $bar is of type int or to say that $bar is whatever
> it is, but will always be forced into an int when its value is taken
> (much like the behavior of Perl6 hash keys)?
The middle one.
The thinking is that a -> would indicate what the preceding referent
was expected to evaluate to. So:
sub foo -> Bar; # foo() expected to evaluate to a Bar
my $foo -> Bar; # $foo expected to evaluate to a Bar
# and, indeed, restricted to aceepting
# a Bar on assignment
It's no different from:
sub Bar foo;
my Bar $foo;
except syntactically.
(And that's why it's probably a bad idea)
Damian
