There is an interesting discussing taking place here: ~Escapable, Span, Ownership Annotations, etc.
There, phrases such as mutating get and mutating mutate are being used. To me, as a user, they sound pretty bizarre and mind rattling.
Why are they creeping into the language? Are there no better alternatives?
I apologise if I offend anyone by asking this question.
mutating get has existed at least since Swift 3.1 (that’s the oldest Godbolt supports) 
mutating get has always been around. The default is this combination, but all four combinations are allowed.
struct S {
var property: Int {
nonmutating get { 0 }
mutating set { }
}
}
Language Reference: The Swift Programming Language (TSPL) book is the authoritative reference for Swift, offering a guided tour, a comprehensive guide, and a formal reference of the language.
I looked in there, but could not find them. 
I guess, I have to change my mental model of it to internalise the mutating get. It is basically a mutating method that takes no arguments and returns some value.
See also SE-0507: Borrow and Mutate Accessors - #27 by Dmitriy_Ignatyev - there is nonmutating mutate even.
Some combinations are a little jarring at a glance, but in terms of actually explaining/teaching them, I thought it’s as simple as “The first word speaks to how self is passed, the second word says how the value is handled.”
I wonder if people would have preferred, or been more annoyed by, a more explicit syntax like mutating(self) get
No need for that. 
This is just an educational issue. The so calledTSPL book should teach this mutating get concept on day one.
Well, no, maybe not day 1. You went over four years without knowing it existed and without missing it; that suggests it’s okay for it to be an “extra, if you need it” kind of topic. TSPL is supposed to be both guide and reference, though, so it does belong in there somewhere, and it’s not great that that’s gone five years without covering it.
I can very much understand @ibex here and to some degree share the general sentiment. Sure, mutating get has always been there, but I think the point of their question is more about future additions to the language.
This is not to say that we should "freeze" it as is, but must not forget the goal of progressive disclosure. And with that I don't mean to say that we, as a community, have forgotten it! It's just one of those things that are good to be reminded of every now and then, even without something "happening".
I've noticed this often leads to minor clashings between folks here in the forums because it's hard to gauge how "necessary" it is to keep up with everything all at once and from day one. This is unfortunate as often times the "liveliness" of threads here make people think that the discussed feature is going to be super important to know in detail and that soon they will need to change their coding habits to incorporate it. IMO that's an illusion.
I see it this way: The longer Swift is around, the more detailed/niche added features become. Lifetime related keywords are a good example for this. The "OG Swift" tune was basically "We use ARC, value types, and smart copy-on-write because that gives elegant code that is 99 % performant enough". This worked great. Then, certain use-cases from that 1% lead to more explicit ways to control that because they were not performant enough.
Naturally the discussion shifted a lot to those (while they "slowly lost their underscores" 
), but there was no discussion about the other 99% anymore.
In the end I believe it's a good reminder to us for when we discuss these new things that we need to keep progressive disclosure in mind. And at the same time, when looking at the discussion, we need to keep in mind that even posts with high traffic are not an indication that we'll have to soon learn & relearn swaths of established swifty paradigms.
Good talk on Progressive disclosure by @Douglas_Gregor
I actually quite enjoy how many parts of Swift I don't understand, and don't need to understand. I skim new evolution proposals, and if the Motivation section doesn't apply to me, I safely ignore it.
While some folks enjoy learning every corner of a language, I don't think we should ever imply that it's the expectation or the norm. We should celebrate being able to pick and choose just the parts that you care about, without having to learn a ton of things that don't apply to you.
It was mentioned before but this is not always possible, especially with large codebases with many people working on it. Inevitably many niche features will be introduced by someone and now anyone debugging it in the future needs to understand it.
aside: i thought this was a pretty good talk – thanks for sharing. i liked this slide in particular:
however, it did remind me how challenging a task trying to preserve a smooth learning curve is. for example, in the above slide, 'Optionals' are positioned as a relatively simple concept one encounters early. but if i open the 'quick help' popover on the word Optional in Xcode, i feel i'm immediately thrown into the 'deep end' of the complexity pool:
granted, the actual written docs in that menu are pretty good, but the initial declaration that you see is fairly intimidating even to someone (me) that aspires to think they know what all the terms mean.
That seems more like a tooling issue though - one might want more of a progressive disclosure in the generated docs in some way I think.
sure, but i think good progressive disclosure is a holistic issue – there's the inherent complexity of the language and there's the UX of learning about/interacting with it. if you make the language more complex in a way that is theoretically explicable in a nice, progressive way, but the tools that expose people to those concepts don't provide that nice explanation, you don't really achieve the goal. overall i think Swift does a pretty good job of this, but it does seem like something that requires a lot of effort in both thoughtful design and implementation within the development ecosystem. no doubt it's a hard problem.
It took me a while to find it (the use of mutating predates the Swift Evolution process, so I couldn't search for the PR that updated the docs for a given proposal like I usually do) but the reference calls out mutating on methods, although only very briefly:
Methods on an enumeration or a structure that modify
selfmust be marked with themutatingdeclaration modifier.
The only appearance of nonmutating is in the formal grammar, and the list of context-sensitive keywords.
The nearby section on computed variables could get a cross reference to this section, which would let them share a longer discussion of mutating if we add one, or we could just add a sentence there about mutating on getters, setters, and so on. My understanding is that mutating means the same thing on property accessors as it does on methods.
Better reference for mutating and nonmutating could be a good starter PR if someone would like to contribute to the book.
Hello, @Alex_Martini
Your understanding is correct.
The phrase mutating get at first looked quite mind rattling to me, it then dawned on me that a get is really a fancy method that takes no arguments and so it can bemutating.
struct Counter {
private(set) var value: Int = 0
mutating func nextValue () -> Int {
value += 1
return value
}
}
struct FancyCounter {
private(set) var value: Int = 0
var nextValue: Int {
mutating get {
value += 1
return value
}
}
}
I have just learned about this only a few days ago, when I was reading this discussion: ~Escapable, Span, Ownership Annotations, etc.
I was naively relying on TSPL as the source of truth, despite knowing that it was lagging way behind the current state of Swift.
I remain of the opinion that we should have a temporary evolution freeze (one or two years) to focus on bug fixes and catching up with documentation. Furthermore, I believe that every Swift Evolution proposal should also come with documentation ready to be integrated into the TSPL(if applicable).
This is an excellent idea worth implementing, and something also very easy to do. If this were implemented, not only it would help those working on the book, it would also help non-experts reading the proposals.