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.

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.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

# 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);
[download]

Dave.

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... ;)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

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.