[swift-evolution] Enable omitting `let` for constant declarations

[Yuta Koshizawa]

Did you mean the thread "Mutability inference"? What I talked about is
different from it. I am against the idea of "Mutability inference".

What I talked about is just enabling to omit `let` for constant
declarations. It distinguishes the following three explicitly.

> - assignment
> - declaration of a constant
> - declaration of a mutable variable

`:=` makes it possible to distinguish assignments and constant declarations.

-- Yuta


2016-04-01 23:55 GMT+09:00 Radosław Pietruszewski <radexpl at gmail.com>:
> I can’t easily find it, but there’s been at least one thread proposing this exact thing, and there was very little interest in the proposal.
>
> TL;DR is that Swift *by design* wants to make the difference between these three concepts:
>
> - assignment
> - declaration of a constant
> - declaration of a mutable variable
>
> as explicit and obvious as possible.
>
> — Radek
>
>> On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> I think it would be good if the following three declarations were equivalent
>>
>> let a: Int = 42
>> a: Int = 42
>> a := 42
>>
>> and also the following two were.
>>
>> let a: Int
>> a: Int
>>
>> Then constant declarations become shorter than variable declarations.
>> It encourages people to use constants in preference to variables.
>>
>> It also prevents repeating `let` for property declarations and makes
>> type declarations simpler.
>>
>> struct Person {
>>    firstName: String
>>    lastName: String
>>    age: Int
>> }
>>
>> Omitting `let` is consistent with that we don't write `let` for
>> arguments of functions and iterated values in for-in loops.
>>
>> Not `=` but `:=` for type inferences because `=` cannot distinguish
>> whether it means a constant declaration or an assignment to a variable
>> declared in an outer scope. I think `:=` is a natural notation for
>> type inferences because omitting the type from `a: Int = 42` makes
>> `a:= 42`. Because I have not strictly checked if it can be parsed in
>> Swift properly, it may have some other parsing issues.
>>
>> What do you think about it?
>>
>> -- Yuta
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>