Mutability/immutability of variables

[klaseca]

Is there any explanation as to why this approach to working with variables was chosen?

What I don't like about it:

1. Using the directive changes the behavior of the var keyword
2. If the directive is not used, we have no way to declare an immutable variable

If the language does not attempt to set a default behavior for variables, it usually just uses two different keywords. For example, in Kotlin it is var and val, in Swift it is var and let

In Ocaml or Rust, all variables are immutable by default, and if you need to make one mutable, you add the keyword mut

These seem to be two fairly common approaches, and I think it would be logical to use one of them

[Rucadi]

I personally would have just made const-by-default with mut and remove the directive entirely. (So basically, make the directive the default state)

[bartman]

ignore this

I think the README has a typeo. Variables are clearly immutable by default, and "mut" makes them mutable.

[Rucadi]

I think the README has a typeo. Variables are clearly immutable by default, and "mut" makes them mutable.

//> immutable-by-default

is a "directive" that makes the variables immutable by default.

Without it, you need to specify constness with "const" instead of mutableness with mut

[bartman]

Got it. sorry for muddling the water.

[hkjels]

Personally, I would prefer the rust way. Immutable by default and just prefix with mut when needed. Not at all cumbersome in my opinion.

[Nickname064]

Maybe we could add a zc compiler flag to set the default variable mutability ? --default-mutability [mutable|immutable]

[Rucadi]

Maybe we could add a zc compiler flag to set the default variable mutability ? --default-mutability [mutable|immutable]

That's a bad idea, because it changes the semantics of all the code, anything included that uses a different mutability will fail to compile, making the flag useless unfortunately.

Right now is "not that bad", since it's per-file specified, however, in my opinion, the most sane thing to do is being immutable by default and remove the option entirely.

[Nickname064]

I've provided a first implementation in #33, simply replacing the immutable-by-default directive with mutable-by-default, and changing the default compiler behavior. I do agree that removing mutable-by-default behavior would be the sanest option though

[pjz]

Just to put in my pair of pennies, I think there should be no default and the declaration should specify. eg. var/val or var/let or var/const all specifying mutable/immutable as lone keywords.

[Salvakiya]

My opinion on this is... C already has constants. Could just remove the directive altogether and make no changes. if you want immutable just use const.

[Rucadi]

My opinion on this is... C already has constants. Could just remove the directive altogether and make no changes. if you want immutable just use const.

I kinda disagree, mut by default is bad, because it makes it easy to not use const for constant values that are never modified. the better is to use the most restrictive modifier by default (const) and explicitly require to mark as mutable, since you can't get away with modifying a constant.

This makes it easier to reason about code since it removes beforehand the question of "is this modified or not".

Also, most of the variables used in a function are usually const in my experience.

[ullenboom]

I find this discussion interesting because it highlights how ideas around mutability have evolved. Early languages treated variables as mutable by default and used keywords like const or final to mark values as read-only. Later languages made this more explicit with constructs like var and val, so mutability became a local, visible choice. Some modern languages go further and make immutability the default, requiring mutability to be stated explicitly.

Making immutability the default and marking intentional state changes with mut seems reasonable. In practice, mutable variables usually show up in a few well-defined places anyway, such as loop iteration variables that are scoped to the loop. In the end, this is a design choice by the language author. In my view, it is a reasonable one and consistent with current practice.

One place where I’d really like to see how this "feels" in Zen-C is memory-mapped I/O. That’s an area where C is very natural in the microcontroller world: you’re explicitly doing volatile reads/writes through pointers.

I also strongly disagree with controlling mutability via file-wide defaults. Source code should always mean the same thing when read in isolation. Its semantics should not depend on implicit, file-level switches that change how declarations are interpreted.

[SCLDGit]

Throwing in my own two cents for var/let.

[thekovic]

Getting rid of the file-scoped switch should be priority out of these discussions imo; whether const or mut becomes the default is up to secondary holy war arguments.

[Zuhaitz-dev]

For now I won't touch much related to the syntax and whether or not it should be mutable or immutable by default, but as @thekovic said, the file-scoped switch might be more of an issue than a solution.

I will see what to do related to that, but, as of now, the mutability/immutability discussion is low priority. There are many other points that require attention right now.

You all can come to the Discord server, which I think it's a better place to discuss about language design.

Also, as of its nature, I will turn this issue into a discussion, which I believe it's more correct.