On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote:
> J: (scalar junctive to typed scalar)
>
> A scalar junctive, e.g. an "untyped" scalar, can always be silently
> used as and/or converted to a more specific primitive type. This will
> quite frequently result in the loss of information; for example, saying:
>
> my $a = 'foo';
> my int $b = $a; # $b is now C<0>
>
> works, but silently sets $b to 0, because the numeric value of C<'foo'>
> is C<0 but true>.
On the subject of untyped scalars...what does it mean to say that the
conversion is 'lossless'? For example:
my $a = 'foo';
my Int $b = $a; # legal; $b is now 0; is there a warning?
my $c = $b; # is $c 0, or 'foo'?
my Str $d = $a; # no loss
my $a = $d; # no effective change in $a
my $e = $b; # what is $d?
In the above, I would expect that $c is 0 and
my $a = 7 but false;
my Str $b = $e; # ???
What value does $f end up with? (My vote would be '7'.)
Does it have any properties?
Are any warnings emitted?
>
> (iv) ---- Pragma-Controlled Conversions ----
>
> Given the above, and given the fact that our general answer to
> everything is to Use A Pragma ;-), we have the following tentative list
> of needed pragmas. For each possibility, we need to be able to declare
> that a given implicit type conversion will be silently allowed, will
> result in a warning, or will result in an exception.
>
> A (very) rough proposed pragma form, for the sake of argument, is:
>
> use strict conversions; # all on (exceptions)
> no strict conversions; # all off
>
> use strict conversions allow => << cv1 cv2 ... >>; # selected
> conversions are allowed
> use strict conversions warn => << cv1 cv2 ... >>; # selected
> conversions give warnings
> use strict conversions fail => << cv1 cv2 ... >>; # selected
> conversions give exceptions
Seems generally, but I'd like to see this be organized into
hierarchies, like Perl 5 (recent versions) warnings: the Numeric
group would control every form of numeric conversion, the
Truncation subgroup would control everything in the Numeric group
that could end up truncating data (e.g. int -> short), etc.
> S: (string to numeric)
My vote for default: C<allow>
> F: (float to int)
My vote for default: C<warn>
> N: (numeric range)
My vote for default: C<allow>
I also suggest adding an extra pragma:
use rangechecking warn => << Int_to_int >>;
use rangechecking warn => << Num_to_num >>;
use rangechecking fail => << Int_to_int >>;
use rangechecking fail => << Num_to_num >>;
This lets you trade speed for safety on a lexically-scoped basis.
> (vi) ---- Conversions of User Defined Types/Classes ----
>
> It may be useful to allow the same level of pragma-based control for
> user-defined types and classes. For example, a given class Foo may
> wish to be "silently" convertable to an C<int>. One proposed syntax to
> declare the method of coercion/conversion might be:
>
> class Foo {
> ...
>
> to int {...} # or C<as int {...}>?
> }
>
> However, users of such a class could adjust the warning level of the
> given conversion using the alternate syntax given above (v):
>
> use strict conversions warn { Foo => int };
Adding to the 'hierarchical pragmas' idea that I mentioned above...how
about a 'to_int' group, which controlled any type (user defined or
system) that was attempted to convert itself to an int? The
extensions are obvious.
--Dks
