develooper Front page | perl.perl6.users | Postings from January 2020

Re: stolen uint's

Thread Previous | Thread Next
From:
Trey Harris
Date:
January 29, 2020 02:35
Subject:
Re: stolen uint's
Message ID:
CALKJ+EvObTX7-o6-SRNbyoUr0REhWbY3pY2eR1aqtipGkivXTg@mail.gmail.com
On Tue, Jan 28, 2020 at 21:18 Trey Harris <trey@lopsa.org> wrote:

> values, such as 'undefined' and 'Nil' as well as its type.
>
>
And that’s another thing: you’ll notice if you define a `my uint8 $x;` it
will be set to 0. No undefined, no Nil. That doesn’t happen with non-native
numeric values.


> Nope. If I give you:
>
> 0x41
>
> and tell you that’s a single octet, and that’s all you have, and I and ask
> you whether that’s an “A” or a decimal 97 or something else described by
> 01000001, how do you answer? You can’t.
>
> Raku knows at compile time—otherwise, it couldn’t autobox into an ‘Int’
> vs. a ‘Real’ for an int32 vs. a num32, for example—but that’s not currently
> exposed to the runtime; you can pitch a new feature, but it would be
> necessary to know what one would use it for to design an interface for it.
>
> An ability to cause a failure or exception to be thrown if a given value
> is autoboxed would be much more defensible, I think—“I need to ensure this
> thing doesn’t get munged by something unexpected into a form that my native
> call will barf at” seems more reasonable (though unboxing should prevent
> that in cases where you’re not round-tripping outside of Raku before your
> native call).
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About