> I did try to make sense of his ideas in those diagnostic ways
Yeah, sorry, I seem to have missed your comment earlier.
> To me, const was always meant to be used for things who represent something
> like a physical constant
That's just one usage. In a language like Nim, which takes compile-ti
Yeah, its the language barrier, although all the people involved in this thread
already got the idea right, also cblake.
I understand that there are details to the implementation who change the
meaning of those things, while I try to keep it simple and understand those
things on a practical sid
But... a let can have compile-time parts and run-time parts, like when you use
`let foo = block:`, that may or may not have `static( )` or even macro code
somewhere in between.
I did try to make sense of his ideas in those diagnostic ways (which I think
could add value though maybe not be a high priority), but I guess my
description was not to @ShalokShalom's liking. :-(
It may partially be the language barrier, but your comments are incoherent. You
could replace every const with let and it wouldn't affect program behavior
unless the variable is used in a when or {.compiletime.} context. And you could
replace every let with const as long as the initializer can b
I think you mean that the value could be different each time the `let` is
evaluated? In which case we're saying the same thing — it's evaluated at
runtime, not compile time.
(When something like `let x = ` appears in a proc, there isn't a single
variable `x` whose value changes. Instead, ea
I mean that let can as an example gain input. The value itself stays the same,
but its usage changes. Const will always be used in the same, predictable way,
let can be used in unpredictable ways.
> When something does potentially change, I use let
I don't understand. A `let` binding cannot change; that's what distinguishes it
from `var`. The difference between `let` and `const` is that the latter is
evaluated at compile time.
Alternatively to nimpretty or nimsuggest, there could be a diagnostic message
letting code authors just change `var` to `let` or `let` to `const` as they
think most helps clarity and their plans for code evolution.
E.g., `var-ness unused` or `run-time-ness unused`. I suspect this is the sort
of
The compiler does turn `let` into `const` sometimes behind your back. Maybe
you're talking about nimpretty or your editor.
if you want to roll your own,
import macros
type MaybeStatic[T] = static[T] | T
template constLet[T](id:untyped, v:MaybeStatic[T]) =
when v is static:
const id = v
else:
let id = v
proc f(x:MaybeStatic[int]) =
constLet(y,x)
expandMac
Yes, and the same for variables who can be changed to **let**. So that it is
always clear, what an assignment does.
I think what @ShalokShalom wants is compile-time const inference, so variables
which are not changed and can be computed at compile-time are automatically
inferred as "const".
I dont understand what the problem is, if any.
I order const and let according to the distinctive use case. When something
does change, let and for things who persist all the same, const.
I think it is a good idea, to check (optionally?) if each let interacts in that
way, or if let could also be changed into a const.
I think that way, it is
15 matches
Mail list logo
