Re^2: Why not perl have raw/native type

[LanX]

> you can't prevent somebody from doing:

Actually, all informations are available at compile time ...

Why shouldn't Perl be able to reject it, unless the reference $ref is also typed?

But maybe I'm missing the OP's intention?

[Corion]

Actually, all informations are available at compile time ...

Divining that information is the topic of Escape Analysis, and its far from trivial to find what values will remain local to a subroutine in the general case.

If you want to put more restrictions on the "native" type, maybe you can make this easier, but that amounts to basically having a second set of data types that are not interoperable with the rest of Perl.

[LanX]

Well, my point is that there is a difference between
• "you can't"
• "it is not trivial"

Actually I'd prefer to see a use case from the OP before continuing further.

[dave_the_m]

How about:

# foo() is a sub from a 3rd party library you have no control over
sub foo { my $r = \$_[0] }

my native str $s = "...";
foo($s);

Dave.

[LanX]

Same xxx other colour:

foo needs a function signature with the right type.

And yes I know that subs can be redefined, but change of prototype is also emitting a warning.

Really complicated are lvalue situations like aliasing!

But hey, I never said it's easy... ;)

[dave_the_m]

You call a sub which is declared as accepting an integer arg - so perl pushes an int value dircectly onto the stack rather than the usual pointer to SV. But if someone in the meantime has redefined foo() to be a sub accepting a normal SV argument, then perl won't just do the wrong thing - it will likely crash with a SEGV, or even be a security hole, when it tries to interpret that integer value as the address of an SV.

Dave.