Re: q: nil in tables
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: q: nil in tables
- From: ThePhD <jm3689@...>
- Date: 2018年3月17日 19:06:08 -0400
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.