What if "const" were called "let"

[Matt Cudmore]

I've been using Swift at work for several months now. The language is nice, although the iOS API is no less of a nightmare than before.

The language has reminded me of Go in several ways, one being the availability of var and let, which are like var and const in Go. However, having read some Go code this weekend where const was used within a function body, I realized that while I use let in Swift in all possible places, I have never used const in Go for anything other than package-level values.

I would like to know if many other programmers are using const in Go to convey the intent of immutability even in small local scopes, for example within loops and closures. Further, do you like the idea of declaring immutability wherever possible, or does it add unnecessary information to code where it's clear enough that a variable is read but never overwritten?

As an aside, I have the feeling that if const were renamed to let with Swift-like semantics, for example in Go 2, then it might be used more commonly, or even adopted by the community as a new way of writing code, namely, declaring immutability wherever possible. Perhaps because the word is three characters (like "var") so it invokes the aesthetic sense of symmetry, and perhaps because the verb "let" is more effective and applicable in function bodies, whereas the noun/adjective const is more suited to package-level declarations, hence its use.

I am just curious and would like to see what others have to say about this.

Matt

[Alex Skinner]

Not a fan.  Let doesn't convey anything at all, especially that it is to be a constant value, like const.  

Alex

[Ian Taylor]

The Go const declaration and the Swift let declaration are
significantly different.

A Go const declaration names a constant, which must be boolean, rune,
string, or numeric. It may be untyped, in which case it follows rules
different from those of Go variables.

A Swift let declaration is a fixed binding between a name and a
particular value. The value may have any type. The value may change.
The name may not change. This is not immutable as I usually use the
term. It's a kind of name binding that is not available in Go (or in
C/C++): it's a name for a value where the name can not change.

I think there may well be a role for immutability in Go, but I don't
see a big need for a let statement as defined in Swift. If you don't
want to change a name, don't assign to it. Go isn't too big on the
kinds of defensive programming techniques that are available in some
other languages. This is in part from the experience of the const
qualifier in C/C++, which tends to spread across lots of code but
rarely catches any actual bugs.

Ian

[Matthew Cudmore]

Thanks Ian, I had forgotten that Go's const may be loosely typed.  I'm not sure what you mean about Swift's let. As you will see in this demo, neither name nor value may be changed, but the value can be assigned to another variable or constant. "Name may not change, but value may change" is exactly the behaviour of a variable in any programming language that I've worked with. But all of them allow you to assign a value to another name. http://swiftstub.com/807137594/

In any case, I agree, the semantics of let and const are different, and I don't see an interesting discussion happening here like what I had hoped. A keyword conveys exactly what it is understood to convey by those familiar with its context. Why there was any need for hyperbolic dismissal I don't know.

In any case, community opinion is important. Mine opinion is that "let" is more meaningful and appealing as a keyword complementing "var" yet conveying immutability. I don't suggest that the Go community should even consider such ideas, but my question stands as to how often people are using "const" in Go in local scopes.

Matt

[Ian Taylor]

On Sun, Nov 9, 2014 at 10:11 AM, Matthew Cudmore <cudmo...@gmail.com> wrote:
>
> Thanks Ian, I had forgotten that Go's const may be loosely typed. I'm not
> sure what you mean about Swift's let. As you will see in this demo, neither
> name nor value may be changed, but the value can be assigned to another
> variable or constant. "Name may not change, but value may change" is exactly
> the behaviour of a variable in any programming language that I've worked
> with. But all of them allow you to assign a value to another name.
> http://swiftstub.com/807137594/

My understanding of Swift's let statement, which is extremely limited,
is that if you declare, say, an array or a dictionary using a let
statement, then while the variable must always point to that
array/dictionary, the contents of the array/dictionary may change.
That is what I mean when I say that the name may not be changed--it
must always point to the same object--but the value may be changed.
Assuming I understand it correctly.

> In any case, I agree, the semantics of let and const are different, and I
> don't see an interesting discussion happening here like what I had hoped. A
> keyword conveys exactly what it is understood to convey by those familiar
> with its context. Why there was any need for hyperbolic dismissal I don't
> know.

I apologize if it seemed like I was making a hyperbolic dismissal.
That was certainly not my intent. I'm just expressing my own opinion
about the value of the let declaration. It's different from const and
it's different from immutability. It seems to be essentially
equivalent to a variable declaration for which the variable is never
modified. There is certainly a use for such a thing, but I don't see
it passing the high bar for adding a new concept to Go.

(I apologize if this seems hyperbolic, but remember that every
language feature is useful--otherwise nobody would want it--but every
language feature carries drawbacks, specifically the requirement for
everybody using the language to understand what it means. All
language changes are cost/benefit tradeoffs.)

Ian

[Jason Gade]

I'm pretty sure they changed Swift prior to 1.0 where a 'let' declaration cannot be changed, even if it is an array or dictionary.

I can't find the release notes now. Here's a reference: http://natecook.com/blog/2014/07/fully-value-typed-arrays-in-swift/

I don't have a problem with 'const'; I like 'let', however, in that it reminds the programmer that most things are actually immutable in practice and should be declared that way.

With the restriction of consts to built-in types in Go, I don't see this changing any time soon.

[Nick Patavalis]

On Sunday, November 9, 2014 4:51:20 AM UTC+2, Matt Cudmore wrote:

The language has reminded me of Go in several ways, one being the availability of var and let, which are like var and const in Go. However, having read some Go code this weekend where const was used within a function body, I realized that while I use let in Swift in all possible places, I have never used const in Go for anything other than package-level values.

I' m not familiar with the exact semantics of swift's let, but the Go example you are linking to does not seem to be valid Go. That is, you cannot:

    func f(s string) int {

        const slen = len(s)

        ...

    }

since len(s) is not a constant expression.

 

I would like to know if many other programmers are using const in Go to convey the intent of immutability even in small local scopes, for example within loops and closures. Further, do you like the idea of declaring immutability wherever possible, or does it add unnecessary information to code where it's clear enough that a variable is read but never overwritten?

Const cannot be used to indicate immutability the way you are implying. A const (in Go) is not a "variable" than cannot change once initialized, but more like a name given to a constant expression (practically and expression whose value can be decided at compile time). In this sense its utility in the situations you are describing would be limited.

Unless I'm missing something...

/npat

[Matt Cudmore]

On Sunday, 9 November 2014 17:51:20 UTC-4, Ian Lance Taylor wrote:

I apologize if it seemed like I was making a hyperbolic dismissal.
That was certainly not my intent.  I'm just expressing my own opinion
about the value of the let declaration. 

No need to apologize. It was the other response that raised my brow. It is far more productive and welcoming, when faced with a flawed idea, to explain the problems and share perspective, which is what you've done. This way you don't risk silencing someone from expressing further ideas.

More on Swift's let, it is not possible to modify an array or dictionary value through the let handle. However, you can assign the value to a var, which makes a mutable copy: http://swiftstub.com/942580035/

The exception is when the values of the array or dictionary are instances of a class, in which case you can modify fields of the instance. However, if the values are struct type, the fields will be immutable, even if declared "var" in the struct: http://swiftstub.com/676500384/

I like these semantics, but there are a lot of different concepts to keep in mind. After working with the language for several months, I still feel that Swift offers more features than necessary. Code blocks in Go tend to be short and straightforward, so really there's no unsolved problem here, whereas in Swift the let keyword adds welcome clarity of intent amid sprawling calls into convoluted APIs.

On Sunday, 9 November 2014 19:17:16 UTC-4, Nick Patavalis wrote:

Const cannot be used to indicate immutability the way you are implying. A const (in Go) is not a "variable" than cannot change once initialized, but more like a name given to a constant expression (practically and expression whose value can be decided at compile time). In this sense its utility in the situations you are describing would be limited.

 

Thanks for pointing this out. It is clear to me now that const and let were intended for very different purposes. It would be interesting to have a collection of examples exploiting the power of const. I tried some bit shifting to see what would happen: http://play.golang.org/p/BcC4CPzCAC and laughed when I tried shifting by 1000 and got the compiler error "stupid shift: 1000" http://play.golang.org/p/AscGE7mUQH

Matt

[Michael Jones]

Try this version:
http://play.golang.org/p/NFCi-usA0y

If you think about it, you'll see some if the magic in Go's handling of constants.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kostarev Ilya]

To my mind, term ‘let’ denote neat concept from functional, lexically-scoped languages. But in C-like languages ‘pointers’ is one of central concepts. Addressability is one of major characteristic in Go.

In ‘let a=b+c’ what &a (or maybe *a) would means? Seems Swift has no pointers at all.

-- 
Ilya

[Manlio Perillo]

Il giorno domenica 9 novembre 2014 03:51:20 UTC+1, Matt Cudmore ha scritto:

I've been using Swift at work for several months now. The language is nice, although the iOS API is no less of a nightmare than before.

The language has reminded me of Go in several ways, one being the availability of var and let, which are like var and const in Go. However, having read some Go code this weekend where const was used within a function body, I realized that while I use let in Swift in all possible places, I have never used const in Go for anything other than package-level values.

Swift supports the functional paradigm, as noted on wikipedia.

Go does not support it, instead.

You may also look at Rust for an example of modern system functional language.

 

> [...]

Regards  Manlio

[andrewc...@gmail.com]

Const is a compile time feature - let is run time. The difference is that the compiler knows exactly what a const value contains while the code is being compiled, let is bound to an immutable value at run time as a computation of values in the current scope.

Go does lack immutable types, but this can be emulated using read only interfaces.

[Tahir]

Strangely enough, I seldom use the var keyword. I was fidgety at the beginning about the short var declaration but it's quite handy. It lets my Go prose breathe.

I don't think I see a use case about being declarative about immutability apart from by construct/design (unexported fields/unexported methods, non mutating methods)

What are good cases for using `let` just out of curiosity?

[Chris Hines]

On Sunday, November 9, 2014 1:12:02 PM UTC-5, Matt Cudmore wrote:

... but my question stands as to how often people are using "const" in Go in local scopes

It's anecdotal but I used locally scoped constants several times in one of the methods for the stack package I published recently.

Start here and scan down to see several examples: https://github.com/go-stack/stack/blob/master/stack.go#L98

Chris

[Matt Cudmore]

On Monday, 10 November 2014 21:43:52 UTC-4, Chris Hines wrote:

Start here and scan down to see several examples: https://github.com/go-stack/stack/blob/master/stack.go#L98

 

Nice example. Here, local constant declarations stand in place of comments on magic values. I would put those at the package level if they were used frequently, but in situations where you would write the values inline anyway, local constants stand out more distinctly.

On Monday, 10 November 2014 21:15:32 UTC-4, Tahir wrote:

What are good cases for using `let` just out of curiosity?

I'm not sure about compiler optimizations, etc., but declaring local constants in Swift has allowed me to quickly distinguish variables from the values that are simply meant to be consumed. Many basic tasks require a series of API calls, where you hold return values just long enough to use in the following statements. There can be a lot of preparation before accomplishing what you want, where you have to pass values through hoops until they're useful. Conceptually, for me anyway, those values are distinct from the variables being modified along the way. Having immutable local values seems to reduce the number of moving parts in my thought process.

Matt

[Tahir]

Oh, ok I see. You use the annotation more like a mental tool rather than really needing the `immutability`.

In Go, it  probably translates into having a relatively* short variable name and using the short variable declaration syntax.

Package level variables can just be defined at the top using `var`. Bonus point is that you don't have to worry over whether something has to use `let` or var` I guess.

In general, the advantage of immutability would probably be in terms of concurrency or Garbage Collection but that's not exactly the same topic.

[andrewc...@gmail.com]

Immutability is very valuable documentation too. Knowing something never changes is useful for many reasons.

[Tahir]

Probably yes. At the same time, the safest thing might be to consider that everything can be mutable. That avoids any moral hazard and complexity, especially wrt embedding and multiword objects.