mut keyword, opposite of const

[lcid...@gmail.com]

I am wondering whether it would make sense to add a mut keyword opposite of const.

My personal reasoning would be:

1. personally I am tired of writing const nearly everwhere, when it seems what I mostly want is const as default.
2. introducing in 2020 would allow us to write new code using mut to explicitly state that we want mutability. There would be no change in behavior.
   
3. would allow for additional Core Guideline analysis.
4. mut could perhaps be synonym to mutable.
5. I would not use mutable because it simply is too long to write.
6. finally in 2023 there could be a way of forcing code (maybe only certain namespaces) to be const by default and mutable when explicitly stated.

Sorry if this has previously been discussed / disregarded but could not yet find the discussion.

[Ville Voutilainen]

On 19 December 2016 at 14:29, <lcid...@gmail.com> wrote:
> I am wondering whether it would make sense to add a mut keyword opposite of
> const.
> My personal reasoning would be:
>
> personally I am tired of writing const nearly everwhere, when it seems what
> I mostly want is const as default.
> introducing in 2020 would allow us to write new code using mut to explicitly
> state that we want mutability. There would be no change in behavior.
> would allow for additional Core Guideline analysis.
> mut could perhaps be synonym to mutable.
> I would not use mutable because it simply is too long to write.
> finally in 2023 there could be a way of forcing code (maybe only certain
> namespaces) to be const by default and mutable when explicitly stated.

Not going to happen, because there's billions of lines of code that
would break if const is made the default.

[D. B.]

Yes, but if you would actually read it, you'd see that default const is proposed as an eventual and opt-in feature, with the ability to redundantly specify mut[able] before then just being proposed as a piece of self-training/preparation.

[Ville Voutilainen]

Which part of it is opt-in?

[D. B.]

The below suggests this, or at least that's the impression that I got from the phrases

"a way of forcing" and particularly "maybe only certain namespaces":

> introducing in 2020 would allow us to write new code using mut to explicitly
> state that we want mutability. There would be no change in behavior.

> [...]

[Ville Voutilainen]

On 19 December 2016 at 14:38, D. B. <db0...@gmail.com> wrote:
>> On 19 December 2016 at 14:33, D. B. <db0...@gmail.com> wrote:
>> > Yes, but if you would actually read it, you'd see that default const is
>> > proposed as an eventual and opt-in feature, with the ability to
>> > redundantly
>> > specify mut[able] before then just being proposed as a piece of
>> > self-training/preparation.
>>
>>
>> Which part of it is opt-in?
> The below suggests this, or at least that's the impression that I got from
> the phrases
> "a way of forcing" and particularly "maybe only certain namespaces":

Good luck with that. This non-proposal will drop dead the second it
enters formal review.

[D. B.]

I couldn't care less if it does or doesn't! I just wanted to point out that it's somewhat more nuanced than you're giving it credit for. Presumably because you formed a strong opinion at the outset and now won't budge on it.

[Dawid Pilarski]

so that we have mut[mutable] and mutable keyword? I really doubt it's a good idea. Also reasoning is kind of weak?

As my programs are made of mainly from variables (which are mutable), I do not want to write mut everywhere next to them and I like const much more.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaAGi%2B6ZWYUP72KK2JR-sHisna67GMf3H70PGtjOHwPQg%40mail.gmail.com.

[D. B.]

To clarify, I'm inclined to agree with Ville, and actually like having to write const. I just didn't instantly see this as a breaking change. But if it was opt-in, I doubt I'd be among those opting.

[Ville Voutilainen]

Suggesting that the language rules would be different in certain
namespaces doesn't help. Trying to make
const the default is a complete non-starter, and no amount of begging
and pleading will make me budge on it.

[Arthur O'Dwyer]

On Monday, December 19, 2016 at 4:29:00 AM UTC-8, lcid...@gmail.com wrote:

I am wondering whether it would make sense to add a mut keyword opposite of const.

My personal reasoning would be:

1. personally I am tired of writing const nearly everwhere, when it seems what I mostly want is const as default.
2. introducing in 2020 would allow us to write new code using mut to explicitly state that we want mutability. There would be no change in behavior.
   
3. would allow for additional Core Guideline analysis.
4. mut could perhaps be synonym to mutable.
5. I would not use mutable because it simply is too long to write.

#define mut mutable  // problem solved

Please don't waste anyone's time by proposing synonyms for keywords.

Now, as to whether "mutable" as the opposite of "const" is a good idea...

I'm sympathetic to the idea that every keyword should have an inverse. We have both `const` and `mutable` to force constness/nonconstness on data members, for example. We have both `signed` and `unsigned` for integer types. And there have definitely been times and places where I've wished I could tag a local variable to say, "Dang it, watch out! This variable can't be `const` because it'll be mutated in the loop on line 357!"  Being able to tag that variable as `mutable` would be pretty neat.

But. Given that mutability is the default in C++ (and as Ville said, that won't ever change), the closest analogue I can think of to the `mutable` keyword would be the `auto` keyword in C and C++03. It meant simply "this variable is on the stack", and was the inverse of extern/static. Since it was the default, basically nobody ever wrote it anywhere: `auto int x;` was better written as just `int x;`. The `auto` keyword was so much ignored by working programmers that it was able to be reclaimed in C++11.

Therefore I would hesitate to introduce any new keyword (or even new place for an old keyword, such as `mutable`) whose purpose is just to be the default.  If `auto` is any guide, working programmers will ignore it and then it'll just be dead weight in the standard, ready to be ripped out again in 2023.

If you're really interested in point 3 "would allow for additional Core Guideline analysis", then I recommend starting a new thread or document (maybe here, maybe somewhere else) where you write down exactly what kind of static analysis you're hoping for. What new thing could the static analyzer do if it saw "mut" on a variable or parameter? What new thing could it do with variables or parameters that were neither "mut" nor "const"? If it did these things, how would the programmer's life be improved? Once you've got something concrete there, you could try to convince someone to implement "mut" as an attribute or as a template annotation along the lines of owner<T>:

    using mut<T> = T;  // analyzer knows that this is a deliberately mutable T

But, as I said, I personally don't know what the static analyzer would do with the above information if it had it.  Complain if you didn't mutate the variable? :P  (Some analyzers/front-ends can do this today anyway: "unmodified local variable could be declared const" and so on.)

–Arthur

[Ren Industries]

Why add a new keyword when we already have 'mutable'? 'override' and 'final' aren't keywords (and 'auto' was reclaimed) for the exact reason that we ought not introduce keywords lightly; I don't see the extra 4 letters being a good argument.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/74a5f12f-0bde-4f4f-ac19-7fa3d3126737%40isocpp.org.

[vinc...@gmail.com]

Swift solves this pretty nicely with the let/var keywords:

var foo = 3   // foo is mutable

let bar = 3    // bar is const

Assuming you're happy typing "auto" instead of "var", and depending on your feelings about macros, you could easily implement this for your own code:

#define let const auto

[FrankHB1989]

Several minor points first (some were mentioned above):

1. What is it exactly opposite to? The keyword `const` has more than one meaning.
2. As above, `const` everywhere (literally) seems bad.
3. Why should it be a keyword to help analysis?
4. Seems too bad having `mut` as well as `mutable` in a language. Confusing.
5. Is it worth to break existed code massively?

There can be more problems, if you want things further than just some syntactic sugar:

1. Despite the ambiguity in the meaning/intention of `const`, why do you think making objects immutable (as possible/by default) is the right direction of the style of code in general, in a language which allows first class side effects of expression evaluation?
2. You can define mutability based on the current object model even you know nothing about the exact value representation for every object type. But how can you define immutability as the base, esp. for types has no predefined value equivalence at all?
3. There is only one kind of mutability implied by the current object model. This can be not ideal, but it at least provides some guarantees for easy interops. On the opposite, ultimately, can you insist/assert there can/should be only one exact immutability expected by users of the language? (This problem may apply to so-called `const`-correctness, too. For instance, is `const` enough to allow constant propagation? Is implicit `const` really appropriate on the key type of associative containers?)

[Olaf van der Spek]

I've been wondering about having implicit in addition to explicit..

It'd allow constructors that could be explicit (especially single-argument ones) to be explicitly marked implicit.

That way, compilers could (optionally) warn when neither explicit nor implicit is specified.

Then, maybe, in 10, 20 or 30 years, explicit could become the default unless specified otherwise.

I've thought about mutable in the past too, especially for references. We've now got string_view for const string& (which is const implicitly) so a major case is covered already.