Effect system: filtering tags

> having uncaught exceptions, Uncaught exceptions can be forced to handled by annotating with `{.raises:[].}` > I think we can do that indeed, but I don't see the point of cargo-geiger. It is clearly the source for getting after developers for using unsafe blocks cause they're worse than anythi

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

You can also use `fields` \+ `typeof(currentField) is int`. But usually it's better to change the types so that they reflect what you need to do with them. Objects don't support random access but arrays do.

Can I get this kind of type automatically build by template or macro?

There are two ways to approach this, depending on whether you can have two different tables at a time. import winim type MC_TABLECELL*[wide: static bool] {.bycopy.} = object fMask*: DWORD when wide: pszText*: ptr WChar else: pszTe

Can I get this kind of type automatically build by template or macro?

I am porting some C library. There are 2 types as below, MC_TABLECELLW for unicode and MC_TABLECELLA for ANSI. winimUnicode is bool value which is defined in system library(winim) . The purpose is to automatically use MC_TABLECELL as uniform interface, and select MC_TABLECELLW or MC_TABLECELLA a

Effect system: filtering tags

> if we can build the equivalent of > with this then I'm content. I think we can do that indeed, but I don't see the point of cargo-geiger. Or let's say that we are really far away from the point where we should spend resources on stunts like c

Effect system: filtering tags

Instead of having an `unsafe` keyword, I hope the compiler could be able to detect some unsafe behaviors (dereferencing a pointer before giving it an address; mixing the use of GC'd memory and pointers; having uncaught exceptions, ...) and give a warning about it to the programmer, who can then

Effect system: filtering tags

Part of what is missing both from the Rust facility and the RFC discussion (except for Mamy's excellent list of a dozen missing things..) is that there are several ways to be "unsafe" with important differences. Leaking memory is very different from accessing uninitialized memory is very differe

Effect system: filtering tags

> It's already very clear. Look for cast and addr keywords... if we can build the equivalent of with this then I'm content. The least we can do is have a document written up describing which Nim constructs are considered "unsafe".

Effect system: filtering tags

Araq is right. You can do [unsafe { asm!( ... ) }](https://doc.rust-lang.org/reference/inline-assembly.html) in Rust but access Rust-y tokens (like gcc, Nim & a bajillion PLs). As Obi Wan Kenobi might say, from a certain point of view, you can do _anything unsafe_ in an `unsafe-asm` block that

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

I wouldn't know what you exactly mean by that, but that gave me an idea of trying to flatten all values, if that's even possible? Btw would using the RTTI module std/typeinfo an option? Is it going to be kept. Alternatively I might actually need an intermediate representation like JSON.

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

If you need to index into something, use an `array` or a `seq`?

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

Hello!, I have been struggling to find a way to copy a field to another one, both chosen at runtime from a "sampler", the details of which are irrelevant, but it returns an int that corresponds to the order in which the fields are encountered. Obviously both need to be of the same type. So wit

Effect system: filtering tags

That language right there ... it's condescending and rude for anybody who lacks superpowers in real life. In fact, it's downright disability-phobic. I hope they update this section soon.

Effect system: filtering tags

This part of Rust documentation :P > Unsafe Superpowers To switch to unsafe Rust, use the unsafe keyword and then > start a new block that holds the unsafe code. You can take five actions in > unsafe Rust, called unsafe superpowers, that you can’t in safe Rust.

Effect system: filtering tags

> That way we get the benefit that Rust gets: it's clear what code performs > unsafe memory operations. It's already very clear. Look for `cast` and `addr` keywords...

Effect system: filtering tags

> That's already supported by a .cast block. Oh I didn't know this was already possible, that's neat. > How about we simply follow the Rust way? Rust's rule for unsafe behavior was what I used as a basis to write the RFC. Specifically this portion from Rust's documentation : > Here are the abi

Effect system: filtering tags

How about we simply follow the Rust way? In Nim this could mean: `addr`, `ptr`, etc get an unsafe effect, everything else is implicitly `.notTags: {Unsafe}` and we need to put a `.cast` block around the code using `addr` etc. to make it safe (we could create a macro called `unsafe` which is just

downloading big files

Yeah, unfortunately I think the current FutureStreams implementation is somehow broken. Maybe there is an easy fix though?

Effect system: filtering tags

> possiblity of removing the unsafe tag once the safety issue has been dealt > with That's already supported by a `.cast` block. (I agree with pretty much everything else you said.)

Effect system: filtering tags

> Nice! My gut feeling is we might be able to use this to introduce unsafe tags > in the language around some unsafe constructs (like addr), then by forbidding > unsafe at the top level cast creatively delimit the unsafe boundaries. The discussion around adding a memorySafe / memoryUnsafe effect

could javascript backend make use of new javascript ES6 module support?

Supporting ES6 modules (the compilation generates a single module) can be very useful. I recall trying to include in a web page, two different javascript files, each compiled from Nim, and there were incompatibilities created because each file had global symbols defined that did not work well wi

Effect system: filtering tags

And the PR has been merged!

Fidgets!

New Events System I finally figured out a clean way to re-work how Fidget handles _events_! Even better the user API doesn't change any so my fork require re-writing basic Fidget code. It also keeps the imperative code simplicity. The model used is that events are _captured_ by a node base