They do different things if it's defined vs. if it's undefined. This is preferred to having an if-then test in a single implementation, if they're different enough that you're really writing two functions anyway.
And List is supposed to be vague there. At the level of Any, it can be a list of anything. To be more specific about the result, you need an implementation on specific types instead of on Any; but most of those implementations would be doing exactly the same thing, only the signature being different. Which is silly and wasteful and makes the computer dig though a sea of identical functions for no reason. On Fri, Sep 14, 2018 at 6:41 PM ToddAndMargo <toddandma...@zoho.com> wrote: > On 09/14/2018 03:10 PM, Brandon Allbery wrote: > > On Fri, Sep 14, 2018 at 5:56 PM ToddAndMargo <toddandma...@zoho.com > > <mailto:toddandma...@zoho.com>> wrote: > > > > 'To opt into a non-nullable version of a type add the :D > > "smiley" to it." > > > > This is confusing. And I don't think correct, but I could be wrong. > > Curt stated it a lot better: > > > > If I say "my Int $x", > > $x is now an Int, but an undefined Int. > > > > If I say "my Int $x = 42", > > $x is an Int, but set to a defined value, 42. > > > > ":D" means that the variable is "defined". "non-nullable" is > > a confusing way to state it. > > > > > > Not exactly. "Defined" is a "now" thing; "non-nullable", via type > > smileys, is an "always" thing. It is defined now, and it can never be > > undefined. > > > > To me ":D" means that the variable has something assigned to > > and ":U" means that the variable has yet to have anything > > assigned to it. > > > > If I were to rewrite this, I'd reverse D and U as that > > is the way they evolve. All variables start out as :U. > > > > > > This is the same misunderstanding: what is now, is not guaranteed to be > > so in the future. :U and :D provide such guarantees. Merely being > > defined or undefined right now says nothing about the future. > > > Hi Brandon, > > Thank you! > > My use for the "smileys" is in methods definitions. It tells me > that the variable has to have a value or a null. > > For instance: > multi method kv(Any:U: -->List) > multi method kv(Any:D: -->List) > > is their way of saying I can use either. > > Question, why don't they just say? > method kv(Any: -->List) > > And "List" is really vague, as in what kind of list? > > -T > -- brandon s allbery kf8nh allber...@gmail.com