Effect system: filtering tags

I do not recall once suggesting that one should grep code. I am actually firmly against having to do a compilers job. My point is with forbid now existing the compiler can be modified and features can be added which enable unsafe code to be detected by the compiler. Ideally to me the compiler co

Effect system: filtering tags

> "In Rust there is 2 keywords less to search for, all things considered" is > not a serious argument. Rust Unsafe covers more use case than `addr` and `cast` and also provide CT checks for undefined behavior, but you know this. This discussion is pointless if you don't see how having to grep t

Effect system: filtering tags

At least according to the manual tags are just user defined effects, so it's the effect system as far as my dumb brain can tell. Pointless pedantry aside, why can these operations not be tagged with `Unsafe` or something similar? They are not presently, but I do not see why the compiler cannot e

Effect system: filtering tags

> > Doesn't seem "very clear" to me. > Arraymancer's insanely low level API is not Nim's fault... To be fair, `fromBuffer` is simply there for interop with other libraries, e.g. when accessing a numpy array. It's pretty clear that using it is highly unsafe. I think Clonkk mainly wanted to highl

Suddenly getting infinite genericDeepCopy recursion

After more than a year, I tried again to debug this problem. I got to the root of the issue's code location, to some degree at least. Using current stable Nim 1.6.6. This is how deep I co

Effect system: filtering tags

> But come on, do manually grepping through source code, stdlib and every > dependency used really the best Nim can do? As opposed to what? Grepping for `unsafe` instead? And yes, I actually did code reviews of external packages and do search for `cast` and `addr` in order to find problems. It'

Effect system: filtering tags

> This is not how it works: In order to use/create a ptr UncheckedArray you > need the cast And importc and emit. Also those can be hidden in external dependency and not directly in your code base. > pointer derefs are irrelevant here too Pointer derefs are not the root cause of unsafe memory

Effect system: filtering tags

> Rust unsafe construct is limited in scope On one side, perhaps, but `unsafe{asm}` is not limited at all in its unsafety. I cannot find any mention of "asm" in that geiger package - either in its text, any github issue, or its 7 year version control history. I find those unsafe Rust subset doc

How to check whether parseFloat leads to missing precision

you are right there are a number of cases where the example function does not work. Also it would not have been appropriate given @drkamaleon's use case focusing on performance (why not directly using GMP's mpf_t?). The code you shared is very interesting, the link that is there

How to check whether parseFloat leads to missing precision

the code shouldn't work, for once if you just strip the decimal point you can get such a big integer value that converted to double it will probably be Inf. Ignoring those cases, I think a decimal number without the decimal point might fit or fit not a double, but then not fit or fit exactly wit

How to check whether parseFloat leads to missing precision

I know it's about `float`s. I'm just mentioning `parseFloat` since I'm kind-of trying to make it behave as `parseInt` and throw an Overflow error if that is the case. Basically, I'm working on Arturo and - given a weird error I've noticed - I'm trying to handle floating-point numbers/literals i

Effect system: filtering tags

> You have at least the following to cover : ... This is not how it works: In order to use/create a `ptr UncheckedArray` you need the `cast` and pointer derefs are irrelevant here too (except if you wanna make an argument that we would really do well with nil safety -- I agree on this). Please

How to check whether parseFloat leads to missing precision

it is not really a limit of `parseFloat`, it is a limit of `float`, which is not made for arbitrary long decimal numbers. In particular echo 12312.12123123456786708789878987123812739182739182739182739812739128739182731923 # outputs 12312.12123123457 Run One way to

How to check whether parseFloat leads to missing precision

I've been experimenting with parseFloat and I guess I'm already hitting its limits: parseFloat("12312.12") # => 12312.12 parseFloat("12312.12123123456786708789878987123812739182739182739182739812739128739182731923") # => 12312.12123123457 Run How would you go abo

Effect system: filtering tags

If you just want a report stunt like geiger, it would seem to me that a crude approximation (which is also all geiger is) is probably close at hand with the `use` command of `nimsuggest` \+ "counting & tabulation". _Not_ doing some blanket "unsafety" already could make that more precise (in some

Effect system: filtering tags

> It's already very clear. Look for cast and addr keywords... Unsafe memory access in Nim is not that clear (if we go by Rust's definition): * You have cast, addr, unsafeAddr, importc, importcpp, emit, asm, * a dereferencing operator `[]` * the indexing operator `[idx]` on `ptr UncheckedArr

How to copy a random field into another of the same type at runtime?

Thanks for all your help Araq!