it does no good, ever, that you get to store a Nil value ... in an array
Why do you think the `is default(Nil)` idiom for storing `Nil`s in `Scalar`s
is OK except when the `Scalar`s are inside an array?

I grant that, as jnthn put it in an SO discussing this:

While there is the `is default(Nil)` trick, I'd strongly suggest using some
other value as your sentinel. Trying to use a language feature in a
situation where you don't want the primary behavior it exists to provide
will generally not go smoothly.
So, it is not something most Rakoons are likely to ever want. But that's
the rule that proves the exception -- on rare occasions *some* Rakoons
*do* want to store a `Nil` in an array because it's not a sentinel but a
`Nil` representing a `Nil`.

I still remember very well the discussion where among several people, Larry Wall pointed out <https://github.com/Raku/problem-solving/issues/342#issuecomment-1211027510> that Nil is designed to /not /act like a usual value. Yes, you can bind to it - I suppose if you want it to show up in an array so much, you /could /bind it there, /even though it's a bad idea among the people who know the most about the intents and design of Raku/ -, furthermore, you can set it as a default for a container - but the latter could be as much taken as a skeleton falling out of the cupboard, or, if you don't like this visuals, enough rope to shoot yourself in the foot.

Also, since Arrays don't actually contain all the containers of the universe when they are created - rather just know a way to "animate" new containers - I can imagine that setting `is default(Nil)` may even cause discrepancy somewhere else.

For obvious reasons I'm not going to look for examples of this use in
`Array`s to share them in this thread.

On the other hand, let me show you examples where the lackiness of @variables causes inconvenience, that, in my opinion, would test the patience (and sense of reality) of any newcomer to the language. (To be continued.)

Reply via email to