[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: q: nil in tables
From:       ThePhD <jm3689 () columbia ! edu>
Date:       2018-03-17 23:06:08
Message-ID: CANNiNqJ2nPGbo=rokz0kAbOOzSqQk03B9vVHUAsaFtASbgKSkg () mail ! gmail ! com
[Download RAW message or body]

Having nil in tables is also an immense conceptual boon for people who work
with the C API and userdata. Having a userdata-specific `nil` was extremely
sad for when you wanted to store your userdata in a table, because it
messed with usual language semantics of `if t[key] then ... end`. Now, it
works out of the box and both pairs() and ipairs() behaves just fine, and
`nil` can be used as a proper `nullptr`-alike value!

On Sat, Mar 17, 2018 at 5:58 PM, Duane Leslie <parakleta@darkreality.org>
wrote:

> > On 18 Mar 2018, at 04:08, Coda Highland <chighland@gmail.com> wrote:
> >
> >> On Sat, Mar 17, 2018 at 11:55 AM, Stephan Hennig <sh-list@posteo.net>
> wrote:
> >>> Am 17.03.2018 um 17:06 schrieb Stephan Hennig:
> >>>
> >>> I tend to think tables with nil are constant size or grow only.  So
> >>> here's a stupid question:
> >>>
> >>> What use-case is there to have nil in tables /and/ to be able to delete
> >>> nil from tables?
> >>
> >> Mixed two thoughts into one: What use-case is there to have nil in
> >> tables /and/ to be able to delete (any) values from the same tables?
> >>
> >> Best regards,
> >> Stephan Hennig
> >
> > One realistic example: Imagine a cache table that holds the results of
> > expensive function calls. The function can return nil, so you have to
> > be able to store that, and you need to be able to remove entries in it
> > as they become stale.
>
> I think this is where a tuple type should exist.  The set of arguments (as
> captured by `...`) and the set of return results (I believe only captured
> by passing as arguments to another function) are naturally tuples and
> require the special `select` method to manipulate.  If you stored the empty
> tuple or the tuple containing only nil this would represent the two
> possible returns without needing to store `nil` in the table.
>
> Regards,
>
> Duane.
>

[Attachment #3 (text/html)]

<div dir="ltr">Having nil in tables is also an immense conceptual boon for people who \
work with the C API and userdata. Having a userdata-specific `nil` was extremely sad \
for when you wanted to store your userdata in a table, because it messed with usual \
language semantics of `if t[key] then ... end`. Now, it works out of the box and both \
pairs() and ipairs() behaves just fine, and `nil` can be used as a proper \
`nullptr`-alike value!<br></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Sat, Mar 17, 2018 at 5:58 PM, Duane Leslie <span \
dir="ltr">&lt;<a href="mailto:parakleta@darkreality.org" \
target="_blank">parakleta@darkreality.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">&gt; On 18 Mar 2018, at 04:08, Coda Highland &lt;<a \
href="mailto:chighland@gmail.com">chighland@gmail.com</a>&gt; wrote:<br> <span \
class="">&gt;<br> &gt;&gt; On Sat, Mar 17, 2018 at 11:55 AM, Stephan Hennig &lt;<a \
href="mailto:sh-list@posteo.net">sh-list@posteo.net</a>&gt; wrote:<br> &gt;&gt;&gt; \
Am 17.03.2018 um 17:06 schrieb Stephan Hennig:<br> &gt;&gt;&gt;<br>
&gt;&gt;&gt; I tend to think tables with nil are constant size or grow only.   So<br>
&gt;&gt;&gt; here&#39;s a stupid question:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What use-case is there to have nil in tables /and/ to be able to \
delete<br> </span>&gt;&gt;&gt; nil from tables?<br>
&gt;&gt;<br>
&gt;&gt; Mixed two thoughts into one: What use-case is there to have nil in<br>
<span class="">&gt;&gt; tables /and/ to be able to delete (any) values from the same \
tables?<br> &gt;&gt;<br>
</span>&gt;&gt; Best regards,<br>
&gt;&gt; Stephan Hennig<br>
<span class="">&gt;<br>
&gt; One realistic example: Imagine a cache table that holds the results of<br>
&gt; expensive function calls. The function can return nil, so you have to<br>
&gt; be able to store that, and you need to be able to remove entries in it<br>
&gt; as they become stale.<br>
<br>
</span>I think this is where a tuple type should exist.   The set of arguments (as \
captured by `...`) and the set of return results (I believe only captured by passing \
as arguments to another function) are naturally tuples and require the special \
`select` method to manipulate.   If you stored the empty tuple or the tuple \
containing only nil this would represent the two possible returns without needing to \
store `nil` in the table.<br> <br>
Regards,<br>
<br>
Duane.<br>
</blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]