Marton: apologies for badly characterizing your post. I particularly
wanted specify the breakage you mentioned for any beginners passing by;
got delayed and forgot about some of your post.
I just mentioned the basic dual nature of Nil. There is a lot of
complexity around 'Nil' and around containerization, without using
them together.
Restating my initial point: Deprecating 'undefine' is just making
something easy more difficult. Not finding any justification for this
change, I now see it as self-inflicted bug scheduled to arrive soon.
I have had some thoughts similar to yours about how containers might be
implemented, but I think education about the current state is a good path.
That could be more docs, and also callables which may have little point
but as educational demonstrations.
Rob
On Fri, Mar 17, 2023 at 04:58:30PM -0400, rir wrote:
> Marton, I am not sure of your meaning. I took the warning message as:
>
> For Scalars assign a Nil, for Arrays/Hashes/Etc. use Empty or ().
>
> Because you might be read as suggesting "@ary = Nil should undefine @ary";
> I will point out that will conflict with:
>
> @a = Nil;
>
> which is defined to assign the RHS entry to the first element of @a.
> I suspect there is no way to destroy a container but to smash it into
> a scope wall.
>
> Some day I shall get serious about understanding Raku's containers.
> In the meantime, I'll just keep creeping up on them and observing.
>
> Rob
>
>
> On Tue, Mar 14, 2023 at 01:38:22PM +0100, Polgár Márton wrote:
> > On 2023. 03. 14. 4:42, rir wrote:
> > > undefine seen at:
> > > <unknown file>, line 1
> > > Will be removed with release v6.e!
> > > Please use another way: assign a Nil; for Arrays/Hashes, assign
> > > Empty or () instead.
> > >
> > > Will that deprecation require a conditional and two assignments
> > > for mixed data?
> > >
> > > [$a, @a, $b, %c, $c, &d].map: { .&undefine};
> > >
> > > [$a, @a, $b, %c, $c, &d].map(
> > > { $_ = $_ ~~ (Associative,Positional).any ?? Empty !! Nil });
> >
> > And even those ways don't seem too convincing... after all, it's more a
> > question of containerization if assigning Nil will cut it or not. I didn't
> > know about undefine but it appeared to me as an issue that you can just
> > assign Nil to an Array and get something that is not the default value -
> > moreover, it doesn't even evaluate to boolean False!
> >
> > It seemed like something that can wait and that could cause a lot of
> > friction as a breaking change but I think it would make overwhelmingly more
> > sense to make Nil always set the default. It is a special value of a special
> > singularity type on its own; it's questionable whether it should ever appear
> > as an assigned element of a composite container but to make it STORE in a
> > special, resetting way, seems kind of a no-brainer, apart from the
> > "breakage"...
>
