Proposed table changes - get and getOrDefault

`{.this: self.}` is a Pragma.

Proposed table changes - get and getOrDefault

@Varriount \- it's just a matter of what you want to be consistent with. `mapIt`, `filterIt`, and `sortedByIt` seem _really_ popular and `filterIt` at least goes back to 2011. This may be a naming convention too old to change, realistically. `withItem`/`item` (choosing consistency with iterator

Proposed table changes - get and getOrDefault

Personally, I don't mind the _mechanic_ behind `it`, however I do dislike the name `it` \- I'd much rather use `this` (or `expr`, if `expr` wasn't already used as a deprecated type name).

Proposed table changes - get and getOrDefault

After posting this, I thought of a maybe better name: `withIt` that tracks more a `sortedByIt` convention applied to `withValue` instead of `mgetOrPut` style naming. The name is updated in the linked-to `adix/lptabz.nim` example impl & this post is to shrink confusion.

Proposed table changes - get and getOrDefault

Maybe `it` notation (from `sortedByIt` fame) is also an abomination (or maybe only in combination with `do`), but you can do a pointer free, view type free, classic Nim (template impl at [lptabz.nim:587](https://github.com/c-blake/adix/blob/master/adix/lptabz.nim#L587)): import a

Proposed table changes - get and getOrDefault

`tables.withValue` is a bit of an abomination - it requires a mutable table even for read-only cases _[and](https://forum.nim-lang.org/postActivity.xml#and) it unnecessarily exposes a `ptr` with all its issues (lifetime etc) - if anything, it should be deprecated, not used as a rationale for in

Proposed table changes - get and getOrDefault

I said: > to have a **_new_** 2-body template If you click on my use case then you might see I was proposing a less cumbersome to use template that satisfies the laziness ideas (although you may have the sketch of an idea to impl it on top of the existing `withValue` outside of the `tables` mo

Proposed table changes - get and getOrDefault

> Rust can do it because it can expose interior pointers Rust can especially do it because of `FnOnce()` , a function with state. `or_insert_with` gets the value to be inserted as `FnOnce()` and therefore the computation can be delayed. This is the (CBN-related) alternative that I mentioned abo

Proposed table changes - get and getOrDefault

> Another way to address both is to have a new 2-body template (I called this > editOrInit in adix/lptabz.nim) there's already `tables.withValue` which I think is what you're describing but it's less flexible than the proposed `getPtr` from , eg see

Proposed table changes - get and getOrDefault

> It would be really nice to provide an analogue of the Entry type with its > API: > > > It's extremely ergonomic. Rust can do it because it can expose interior pointers in a type-safe manner (it's called "borrow checking") an

Proposed table changes - get and getOrDefault

> As Options are not a core element of the Nim language, I generally avoided > their use In my opinion, the nice and clean way to handle missing values is in TypeScript and Kotlin (and proabably other languages I don't know) with `const v: string | null` with total null-safety and autocasting s

Proposed table changes - get and getOrDefault

you hit the nail on the head, but we do have (pseudo-) lazy-evaluation in templates, which work well enough that I wouldn't call them a hack.

Proposed table changes - get and getOrDefault

We have templates for this. See `sequtils.newSeqWith`.

Proposed table changes - get and getOrDefault

> table.getOrDefault(1, createAString("ONE!")) will ALWAYS invoke > createAString, even if not needed. It would be useful to have this only > execute when necessary. You want call-by-name. Alternatively, you could wrap it into a closure. But then, the callee has to know that it has to call the

Proposed table changes - get and getOrDefault

@Prestige > table.getOrDefault(1, createAString("ONE!")) will ALWAYS invoke > createAString, even if not needed. It would be useful to have this only > execute when necessary. You want call-by-name. Alternatively, you could wrap it into a closure. But then, the callee has to know that it has t

Proposed table changes - get and getOrDefault

There is an entry type in `tables` impl (`KeyValuePair`), but it is unexposed/unexported. What my `template` does is let the user manipulate a Nim `ptr` to their own `V` value type..and they presumably understand their own types. { We can hope, anyway! :-) } Maybe not the safest thing ever, but

Proposed table changes - get and getOrDefault

It would be really nice to provide an analogue of the `Entry` type with its API: It's extremely ergonomic. It would provide a bunch of very useful operations while avoiding double lookup or copying. Separating this would allow

Proposed table changes - get and getOrDefault

Another way to address both in one addition is to have a new 2-body template (I called this `editOrInit` in [adix/lptabz.nim](https://github.com/c-blake/adix/blob/master/adix/lptabz.nim#L574)) that just has a user-given body for both the found & missing branches with no exceptions. Example use

Proposed table changes - get and getOrDefault

* see for 1st part * see for 2nd part, in which I'm proposing `getPtr` instead of `Option` (see rationale)

Proposed table changes - get and getOrDefault

> It would be useful to have a get proc that returned an Option instead Can you tell us how big the overhead of Options is, for code size and performance? As Options are not a core element of the Nim language, I generally avoided their use in the last seven years. I used a special marker instea

Proposed table changes - get and getOrDefault

I'd like to gather opinions on changes I want to propose for the tables module. Please leave any thoughts or suggestions you may have. ### getOrDefault Example: import tables let table = {1: "one", 2: "two"}.toTable proc creat