On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote:
>
> *: (undefness and properties lost)
>
> Using/converting an uppercase type as/to a lowercase (primitive)
> type is silently allowed. If you're sending an Int to something that
> requires an C<int>, you know that the 'something' can't deal with the
> undef case anyway -- it doesn't differentiate between undef and zero.
> Thus, you meant to do that: it's an "intentionally destructive"
> narrowing, and the C<undef> becomes a C<0>.
>
> my Int $a = undef;
> my int $b = $a; # $b is now C<0>, NOT C<undef>
I'm not sure what "silently allowed" means here (compile time perhaps?)
but I'd certainly want that to generate the traditional "Use of undefined
value" warning (controlable via the perl6 equiv of the warnings pragma,
but defaulting to enabled).
> F: (float to int)
>
> Historically, accidentally using a float as an int can be a
> significant source of errors. Proposed pragma variants:
>
> use strict conversions allow => << num_to_int >>; # which is the default?
> use strict conversions warn => << num_to_int >>;
> use strict conversions fail => << num_to_int >>;
I don't see a problem with compile time warnings by default *if*
there's an easy way for the developers to express the fact that
they know what they're doing (easier, that is, than wrapping the
assignment in a { use strict conversions allow ... } block).
Something like a cast function would fit: $int = int($num);
> N: (numeric range)
>
> This one is a giant pain. Converting, say, an Int to an int will,
> in fact, fail to do the right thing if you're in BigInt territory, such
> that the number would have to be truncated to fit in a standard <int>.
> But 99% of the time, you won't be working with numbers like that, so it
> would seem a horrible thing to disallow Int --> int and Num --> num
> conversions under the remote chance you *might* be hitting the range
> boundary. Then again, it would seem a horrible thing to hit the range
> boundary and not be informed of that fact. Thus, deciding the default
> state here will be a challenge:
>
> use strict conversions allow => << Int_to_int >>; # which is the default?
> use strict conversions warn => << Int_to_int >>;
> use strict conversions fail => << Int_to_int >>;
>
> use strict conversions allow => << Num_to_num >>; # which is the default?
> use strict conversions warn => << Num_to_num >>;
> use strict conversions fail => << Num_to_num >>;
Same as above. I could live with a compile time warning if it's
trivial to silence it for a particular assignment.
But I'd also like separate control over the detection and behaviour
of underflow / overflow / loss of precision etc at runtime.
So if I assign an int a value that's too big (from a Int, or Num,
or untyped scalar), I would like to know about it. Similarly for num.
> (v) ---- Alternative Pragma Form ----
>
> An alternative pragma form could possibly allow finer control over
> every individual possible conversion. The disadvantage of this form is
> that it would be very difficult to "correctly" set each of the >100
> cells of the matrix, or even the 14 "critical" cells that most often
> change:
Perhaps it would be better to think in terms of "styles of coding"
or "policies", and aim to meet those needs with simple pragmas
(implemented on top of a more general mechanism).
Basically, do both. The simple forms could just be an interface to
the more general.
> (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 };
For
my int $int = $foo;
isn't the int() method (vtable entry) called on $foo? (effectively)
So the $foo object is asked to provide an int for assigment to $int.
So the Foo class gets to decide how to do that.
In which case what you're proposing requires either
- the compiler to write the code to pass extra flags to the int method
- the compiler to write call a different int method (eg, int_warn())
- for the int method to look at the calling context to get flags
Please correct me if I'm wrong (which I could easily be as I've not
been following any of thise closely).
I think this is an important topic because it may reflect back on
how the specific Int/Num/Str classes should also be handled.
Tim [quite possibly talking nonsense]
