The point of optional, gradual typing is to offer optional type safety. If I say "String", it must be defined and have an appropriate string value. Thus, undef would cause an exception. I would suggest that any non-overloaded reference would also throw an exception (No more printing out ARRAY(0x7fecea803280)). However, if stringification is directly overloaded, we'd have to respect the intent because printing DateTime->now is intended to work. The integer 42 would need to stringify to 42 because even Java allows this as the one case of operator overloading because it's so damned useful.

That being said, I could be smoking crack. And I'd want these to be exceptions, not warnings, because I find so many ways in which warnings can be overlooked.

The point of optional, gradual typing is to offer optional type safety.

This seems like a tricky feature in an allomorphic language like Perl, where intrinsics are polymorphic and operators are monomorphic.

I would suggest that any non-overloaded reference would also throw an exception.

I think there are cases where default stringification is desirable, and I suspect you'd have to go through each operator and each intrinsic to come up with a matrix of where it might be useful. This seems like a similar problem to smart match (though less so, because stringification for types should be a unary op, not a binary op).

I'd be quite fine with eleven different opinions on how Str should be implemented. The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

It is the subtle differences between Perl's (CPAN) object systems which drives me nuts, not the individual behaviour of any of these systems. I can live just fine with any of them, but having more than one in a project, which is inevitable for bigger projects, hurts.

The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

Agreed. And since there are already multiple competing modules to handle type constraints and OO in general any Perl programmer could happily ignore anything added to the language and continue to use their existing favourite module because TIMTOWTDI.

having more than one in a project, which is inevitable for bigger projects, hurts.

Ain't that the truth. It certainly looks like that particular horse has long since bolted, unfortunately.

since there are already multiple competing modules to handle type constraints and OO in general

My main point is that Perl should provide an API for those existing competing modules to hook into the same syntactic sugar within a particular scope. I don't have any problem with there being a core way and alternatives on CPAN.

The choice is there being multiple type constraint systems which each have their own syntax, or multiple type constraint systems which at least can take advantage of a common syntax.

Like how Moose, Mouse, Moo, and hand-crafted classes can all use ClassName->new(%params) as their constructor. You can write your constructor differently, like ClassName::get_factory(parameters => \%params)->new_object() but except in unusual circumstances, most people would prefer to ease cognitive load by using the common pattern.

toby döt ink