To me it seems clear that regular users generally prefer it the way it is.
However I do not believe dom96 would make this post if he were not getting
consistent feedback about this front potential adopters. I believe that signal
should not be ignored. If the feature isn't being removed maybe it
**I do not want a vote** , however, I think that "the decision makers" should
read the thread and see if any arguments stand out to them or change their view
and do what they feel best. That being said, I like @LibMan's third suggested
option...
* The compiler should generate a warning, but t
> PS: Can we not edit our own posts?
You can, don't you see a pencil button on your post?
I just read that dom prefers "I want a vote" or "I don't want a vote", but
actually I don't really care about the style insensitivity either way. I think
many people who dislike it do so largely because they think of it as "impure"
for people to have to care about style sensitivity (e. g. you ar
PMunch wrote:
> And after having had to write some code in C and Ruby that doesn't have it
> I'm > even more for it.
I can not speak for C but in ruby you can make use of aliases.
So:
> def foo_bar end; alias foobar foo_bar
This may be excessive to want to do so manually but you could batch-g
Personally I do not care either way. To me the issue of case sensitivity or not
has never been one that existed.
For me personally the biggest problem is time :D - however had, past that
point, I may wish to be able to use a "sub-dialect" of nim that is more
light-weight in syntax. For example,
PS: Can we not edit our own posts? I did want to edit it to clarify what I
meant ... but I can not see an edit-button or so. I only see "reply", a heart
icon, and the time ... quite strange forum here. Is it written in nim? :) I
swear this also changes every some months... :P
> For me, coding is a hobby
For me too. My biggest issue altogether is lack of time. Ruby is my main
language but I do not even get to write as much code a I once did, simply
because I don't have the time. I still write code to solve things though, many
trivial things that come up every day.
>
Use `readAll`:
[https://nim-lang.org/docs/asyncdispatch.html#readAll%2CFutureStream%5Bstring%5D](https://nim-lang.org/docs/asyncdispatch.html#readAll%2CFutureStream%5Bstring%5D)
I'm for not voting. As said previously this appears to be more of a
religious-like issue more than anything else. For me, an amateur hobbyist
programmer, I'm in favor of case insensitivity, however ignoring the
underscores does seem to be more non-intuitive.
On a similar note, Nim has Uniform F
Yay! No more `nil` deference on strings. Awesome!
@juancarlospaco Thanks! I'm happy about the pure functions.
Don't cast to refs, strings or sequences, those types are tracked by the
garbage collector and the cast will not register those pointers with the
garbage collector.
Also I'm surprised you can have a typedesc field as in:
type
ListClass = ref object
typ : typedes
Note that casting to a `ref` instead of a `ptr` is usually not safe.
Hi, please help, what do I do wrong?
proc getData(urlR: string): Future[(bool, string)] {.async.} =
var client = newAsyncHttpClient()
var r = await client.request(url = urlR)
result = await r.bodyStream.read()
var r = waitFor
getData("https://pde.cit.api.he
Thank you mratsim. I will use ByteAddress instead of int. Anyway, Can you
please guide me on this ?
type
ListClass = ref object
typ : typedesc
pointR : ByteAddress
var x = new ListClass
x.typ = string
x.pointR = cast[ByteAddress](addr
Ok, i 've got the partial answer.
var s = cast[ref Sample](p)[]
Run
Now, one question arises. Is it possible to keep the type name and use it when
needed ? I mean ;
var abc = Sample
var p = cast[int](addr(abc))
Run
By this time, i know
You can `cast[ptr T](yourInt)`, and to dereference: `yourPtr[]`.
Instead of `int` I strongly suggest you to use `ByteAddress`.
Here is an example of using pointer<->int conversion to align a pointer on
64-bit boundary.
[Source](https://github.com/numforge/laser/blob/432e8f22ae63e798a9dcf49f2f2d
Hi all, I have 2 questions.
1. How to convert an integer to pointer ?
2. How to dereference that pointer ?
See this code sample
type Sample = object of RootObj
intVar : int
strVar : string
var abc = Sample
var p = cast[int](addr(abc))
Case typos are not a big issue. Compilers errors messages will points you in
the right line.
If you import C identifiers (or other languages) style insensitivity may
introduce hard to find bugs. In some cases the compiler can silently replace
a_thing by aThing . It's less common than typos, but
For me, this idea of voting is strange and even makes me uncomfortable. Does
the creator of the language agree with this procedure? If this is not the case,
we are following a wrong path here.
Moreover, are we going to vote for each presumably controversial topic, for
instance the syntactically
Try `nim devel`, it contains a bugfix for this, that was also backported into
0.19.2 (release pending).
I'm against changing this, and I think a vote is superfluous so **I do not want
a vote**.
When I first found Nim I though the style insensitivity was a bit strange. But
the more I use it the more I like it. And after having had to write some code
in C and Ruby that doesn't have it I'm even more
The `func` is more funky now. The `future` is now `sugar`. `httpbeast` is
fastest Server (for JSON data). A lot of cool modules on Nimble.
I agree, but I do think it is a bit funny that you view your gadget as a
blocking feature and fibers as something much less important. Both are equally
"gadget"-y, as none are really needed for async io. Callbacks/promises/futures
and optional posix threads will get you there.
In my view, fiber
24 matches
Mail list logo
