No =destroy hook(s) in std/tables?

I'm looking into this issue. There is another workaround using `var T` destructors: proc `=destroy`(x: var BObj) = echo "Destroying B named ", x.name `=destroy`(x.name) `=destroy`(x.tableField) # Workaround for lack of =destroy in Table Run

proc/func/method: syntax

I believe everybody is afraid to have their code being now incompatible. This must be a joke.

Should conversion outside of a range result in a Defect

The following program emits from the conversion a RangeDefect when the input isn't in the range, and from parseInt a ValueError when it's no a number at all: import std/strutils type myRange = range[1'u8..128'u8] proc foo(x: myRange) = discard foo(stdin.readLine.pars

Should conversion outside of a range result in a Defect

How about this ? import std/strutils type myRange = range[1'u8..128'u8] proc foo(x: myRange) = echo("got : ",x) #foo(129) # In my head should be a compile time error, which it is let inp = parseInt(readLine(stdin)) proc checkMyRange(value

NIR

Using something like LLVM IR can be good if you want to use the LLVM framework, but it is designed to generate assembly code, not C code, and it'ß designed around the C language, it would probably miss a few features for Nim.

Should conversion outside of a range result in a Defect

Use the compiler flag `--rangeChecks:on`

Should conversion outside of a range result in a Defect

This is true but I was excepting to be able to use a range as my way of verifying user input, in my real world use case it wont be user input, it'll be non Nim code calling this code, and instead of a range of `[1'u8..128'u8]` it'll be `[0.0'f32..100'f32]` and I cant enforce that representation

Should conversion outside of a range result in a Defect

Its your responsibility to verify user input. If you allow out of range values you're opening the gate for invalid state and undefined behavior for your application.

Should conversion outside of a range result in a Defect

I am currently playing around with ranges in my program, and my goal is to limit what a user can supply to a proc, either with a compiler error or an exception if at runtime. Currently the compiler error will happen, but if your error is at runtime you will get a RangeDefect, I'm not very well v

NIR

Future compostionality (re)assurance :-> And probably exercise :-]

browser automation recommendation?

Browser automation is fragile, it's better to use mature libraries. I would compiled Nim to JS and use Puppeteer.

Nim Community Survey 2023

Yes . They are too scarce . Everything in 2.0 not need take 2 year to release ( time between 1.6 and 2.0 release ) .

Nim Community Survey 2023

Could you elaborate? Is this about the timing of nim releases?

Nim Community Survey 2023

Biggest missing thing : **More Often Versions** .

No =destroy hook(s) in std/tables?

Your workaround fixed the problem. Thanks very much! For completeness, the modified code is below: import tables type AObj = object name: string proc `=destroy`(x: AObj) = echo "Destroying A named ", x.name `=destroy`(x.name) type BO

proc/func/method: syntax

Make that 2 spaces and we're talking.

NIR

Just a question: intermediate language representations also exist for LLVM, and there are other vm implementations that are low level. What made you choose your own over their supposedly mature and tested AST?

Guardian Blood Balance Australia

Official Website@:- Guardian Blood Balance Australia:- > It supplies all the important necessary for your body. All the natural > ingredients present in this formula maintain healthy blood pressure levels, > blood glucose levels, and cholest

Nim Community Survey 2023

Nim Community Survey 2023 is here! Read more: Fill the survey:

proc/func/method: syntax

> This thread is surprisingly long. The idea is just bad on so many levels, > it's really weird seeing such a vast discussion grow around it :-) Wait until you hear my novel and unique idea that all Nim code should have mandatory 4-space indentation!