-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap for Nim #437
Comments
Not sure how I feel about this. Would this also imply removal of the same feature for NimNodes? I rather like that (i.e. specifying a CT proc is only for idents). To be fair I didn't know this could be used with runtime procedures. |
Reminds me,
Would |
Yes, most people would like that better but I don't want to implement and support |
So eventually, |
No, for the return type and discard-checking there would still be a |
+1 for
why implementing and supporting package.module.name needed for package/module/name? |
Update: Expanded the section on Nimble. |
But stdlib keeps |
|
I believe that this is because If an expression like |
Update:
|
Would be nice to give the jsgen some love too!, at least improve jsgen a little, |
What is policy for breaking changes in 2.0? I see 2 extreme options:
Some concrete examples I know:
|
We should fix as much as reasonable, but we need to have a good upgrade path. The worst thing continues to be subtle changes in runtime behavior. That means:
|
Very cool, nice roadmap. What's the current status, what is the primary project being worked on?
1.6.2 is now out, but there hasn't been any updates to that PR. What's the status of it? |
I never know how to update these RFCs. 1.6.2 is out, next week work on 2.0 will begin. |
There is nim-lang/threading which is official plus a couple of external packages that do it better than we could hope to. There are currently no plans to bring this into the stdlib for these reasons:
We merely offer the building blocks with destructors, atomics and |
Note for the checklist: guards & locks are in both experimental features to clean up and stable experimental features. Since guards were moved to the stable documentation, it can be marked under the stable experimental features section. Some RFCs covered by the items: A few simple non-breaking features that could be done at any time, but would be nice to have soon, probably also under 1.6 line:
There are also tons of RFCs related to default object fields and pattern matching but they tend to be larger in scope and discuss other things. I think "optimize away empty tuple" will take a while compared to the steps for removing the other experimental features. But since it's not tied to a super well known experimental feature it should be fine if it's not 2.0. Does the
Don't understand this. Is it supposed to be kept in as experimental but undocumented? |
I just got reminded, is there any chance |
Alternative way is to support vmmarshal properly with callback if it is worth. |
@beef331 wow... that should be fixed indeed. It doesn't necessarily mean we need to disable marshal on the VM though, it should simply either use its own opcodes or the existing callback mechanism. |
A simple POC using callback mechanism: https://gist.github.com/xflywind/551d84567cb39d95d0ddcd71f8279e6a |
Could we consider #89 for nim V2? A few options have been considered, eg the linked RFC, or deprecating naked |
I would like to re-consider ideas proposed before this Nim 2.0 trend, like:
|
Slightly related to arne's point. In my quest to make code more reusable I did attempt to make parseutils use proc doThing(oa: openarray[char]) = discard
proc doThing(str: cstring) = discard
doThing("hello") Similarly the following perhaps should work. Where type NotString = distinct string
converter toString(s: NotString): string = string(s)
proc doThing(oa: openarray[char]) = discard
doThing(NotString("hello")) |
The Nim 2.0 can also be a good opportunity to make a decision about Nimble packages clean out, |
What about bootstrapping build systems/package managers that use threads? Will they need to supply their own implementation of threadpool? |
No, package managers and bulid systems can use Nimble packages as dependencies if they do the "git clone" commands directly in the build script and/or can use git submodules. A package manager is not like a compiler, it doesn't have to "bootstrap" itself. |
This is not possible in network-sandboxed environments, and support for
them matters.
|
The sandbox would prevent |
I've successfully packaged lots of Nim libraries and programs for
Gentoo, which package manager is network-sandboxed (this is the standard
in *nix packaging). Neither git nor nimble are needed for it.
Seems like this discussion is off-topic and should be over.
|
Fine with me, you started the subdiscussion. |
I like nim, but cross-compiling is inconvenient. I wish I could cross-compile directly like Golang or ziglang, which would attract more users |
Just use a CI, cross-compilation won't let you run any tests anyway... I wish we would attract more users who understand software development. |
Ok, I spent some time cross-compiling using CI: - name: build-x86
image: dockcross/linux-x86
commands:
- nimble build --passL:-static -o:out-linux-x86 -d:release
- name: build-x86-64
image: dockcross/linux-x64
commands:
- nimble build --passL:-static -o:out-linux-amd64 -d:release
- name: build-linux-arm64
image: dockcross/linux-arm64
commands:
- nimble build --cc:env --os:linux --cpu:arm64 -o:out-linux-arm64 -d:release
- name: build-android-arm64
image: ghcr.io/tomasky/drones/arm64:nim
commands:
- nimble build --cc:env --os:android --cpu:arm64 -o:out-android-arm64 -d:release
|
Postponed:
|
Postponed:
|
I'm closing this since version 2.0 is effectively done, we'll only fix even more ORC bugs and release 2.0 in early 2023. The plan for 2023 will be published as an RFC here in the next couple of days. |
https://github.com/enthus1ast/zigcc Just use the Zig compiler 😉 |
It seems to come up regularly that people don't know where Nim is heading, where our focus of development is and what's the PLAN. I'm sorry for not communicating it well but the plan is solid, doesn't change much and it "only" takes longer than I hoped it would take.
Incremental compilation (IC) / nimsuggest / IDE tooling
This is a single point as for me it's a single thing. If we had a compiler that only recompiles the module that was touched the "nimsuggest" tool can be a simple command line tool that answers a single question like "where is symbol X used?".
The good news is that we have this tool already, it's
nim check --navigate
, the bad news is that its progress is tied to PR nim-lang/Nim#17814. Which is in the state "on hold" until version 1.6.2 is out.IC is the most important thing for me personally. It's not scheduled for any particular release as it's not about the language nor about its library. Ideally IC will stabilize and be backported to the 1.6.x line.
Update: Good IC relies on refactorings of the compilation pipeline. We want to finish these refactorings, release version 2.0 and then finish IC in version 2.x.
Version 1.6.2
Version 2.0
Hard goals
For version 2.0 we will make
--gc:orc
,mimalloc
and--threads:on
the new defaults.--gc:orc
koch boot compiler with orc Nim#20467 defaults to ORC Nim#19972--threads:on
default threads on Nim#19368mimalloc
supportsmimalloc
for ARC/ORC (1.15x ~ 1.22x speedup booting the compiler) Nim#20359Furthermore, we consider the following experimental features to be stable enough for version 2.0:
--experimental:strictEffects
fixes #19162; enablestrictEffects
for v2 Nim#19380--experimental:unicodeOperators
Unicode Operators are no longer experimental Nim#20444--experimental:overloadableEnums
overloadable enums no longer experimental Nim#20298-d:nimPreviewFloatRoundtrip
move formatfloat out of system Nim#20195-d:nimPreviewDotLikeOps
enable nimPreviewDotLikeOps Nim#19598Stretch goals
Language
Enforce "Definite assignment analysis" for all types, this is easy to do, removes an error-prone aspect of the language, makes the language more consistent and mitigates the problem with
nil
pointers. Definite assignment analysis and out parameters #378. DAA and 'out' parameters Nim#20506Deprecate 'unsafeAddr' and make 'addr' available for all addressable locations, see Deprecate 'unsafeAddr' and make 'addr' available for all addressable locations #369 deprecate unsafeAddr; extend addr Nim#19373
Support
field = defaultValue
inside object declarations. User-defined implicit initialization hooks #252add default field support for object in ARC/ORC Nim#20480
Cleanup of experimental language features
Stable experimental language features
These features are stable and should be part of the manual.
caseStmtMacros
no longer experimental, experimental manual refactor Nim#19173caseStmtMacros
no longer experimental, experimental manual refactor Nim#19173caseStmtMacros
no longer experimental, experimental manual refactor Nim#19173caseStmtMacros
no longer experimental, experimental manual refactor Nim#19173caseStmtMacros
no longer experimental, experimental manual refactor Nim#19173Library
Clean up the system module, move these submodules into their own modules:
Clean up the OS module, make it more type safe, split it in up in e.g.:
std/paths
,std/files
,std/dirs
,std/symlinks
Nim#20582std/paths
,std/files
,std/dirs
,std/symlinks
Nim#20582std/paths
,std/files
,std/dirs
,std/symlinks
Nim#20582std/envvars
for env vars handling Nim#19421std/paths
,std/files
,std/dirs
,std/symlinks
Nim#20582std/oserrors
for OS error reporting Nim#19390The JSON module is also in a poor shape, the API exposes public fields, sometimes is not intuitive (the
%*
operator) and has poor performance. It could be split up into:More of the standard library should be moved to external Nimble packages. How
far we get with this is unclear.
Misc (in comments)
Version 2.x
Every stretch goal of 2.0 that didn't make it into version 2.0, should be
considered a goal for version 2.x.
Hard goals
We should remove the requirement for forward declarations and allow for recursive module dependencies. Then we can remove these experimental features:
see also nim-lang/Nim#18818
Stretch goals
static
values and stabilize the feature.of Value(let x, var y)
and embrace an official pattern matching solution that makes use of this syntax.Nimble
We hope to be able to ship a new Nimble with the 2.0 release but we are happy to ship it whenever it's ready. See #398 for good ideas of how to further evolve Nimble. The most important missing feature of Nimble is "lock files" -- Nimble implements it, but not in a way that is compatible with the 1.6.0 Nim compiler.
How can you help?
The standard library cleanups should be rather easy to do.
The text was updated successfully, but these errors were encountered: