<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It is an interesting idea all the same, and it would be cool to see it applied in a language like ML that encourages large amounts of let-bound constants and statements. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">~Robert Widmann</div><div><br>2016/02/24 22:21、Darko Damjanovic <<a href="mailto:darkodamjanovic@me.com">darkodamjanovic@me.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>Hello Robert,</div><div><br></div><div>that's great, getting so much highly accurate input about this theme makes me understand better the advantages of the current solution. I appreciate that. Thanks.</div><div><br></div><div>- Darko</div><div><br></div><div><br></div><div><br>Am 25.02.2016 um 03:59 schrieb Developer <<a href="mailto:devteam.codafi@gmail.com">devteam.codafi@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>But that's the thing: I don't wish to encourage mutability through the omission of a keyword. (I don't wish to encourage mutability in any case, but that's beside the point!). Your point about types being implicit is entirely different. If type inference does its job, there is no way to apply a term of a certain type as an argument to a function expecting a different type. The same is not true of this scheme of inference. Because I cannot ask swift to guarantee that terms are mutable or immutable, or specify that a function should be pure, I have no immediate guarantees about the mutability of my variables at first glance. That's a level of uncertainty about my code I wouldn't wish to have for any amount of keystroke savings. </div><div id="AppleMailSignature"><br>~Robert Widmann</div><div><br>2016/02/24 21:34、Darko Damjanovic <<a href="mailto:darkodamjanovic@me.com">darkodamjanovic@me.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><div class="">Hello Robert,</div><div class=""><br class=""></div><div class="">I am doing most of the time application development, so I do not need to take care _so_ much about it. But I assume in case of writing lib’s for external usage this could be important, yes. But If you want to explicitly declare immutability just write „let“. Nothing hinders you, right?</div><div class=""><br class=""></div><div class="">- Darko</div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">Am 24.02.2016 um 23:52 schrieb Developer <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class="">-1. In addition, it would imply that all variables are mutable "by default" (a la Python), because all it would take to change an implicit let to an implicit var would be an accidental extra assignment in another branch somewhere.<br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2016/02/24 16:44、Riley Avron via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">–1. This would make reading and maintaining code appreciably harder for a trivial reduction in character count when writing code. </div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Riley</div></div></div></div></div></div>
<br class=""><div class="gmail_quote">On 23 February 2016 at 23:06, Darko Damjanovic via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the current Swift version the compiler is warning me if a variable is never written to and therefore should be a "let" constant. So now the compiler knows best if "let" or "var" should be applied. During writing code I experience repetitive hints about using "let" or "var" so why do I have to declare it all the time by myself if the compiler anyway knows best?<br class="">
<br class="">
My proposal would be to make the declaration of "let" and "var" optional.<br class="">
<br class="">
Example:<br class="">
x = 0 // <- implicitly declared as "var x" because later was written to, no need to declare it manually<br class="">
x = 5<br class="">
<br class="">
Example:<br class="">
y = 0 // <- implicitly declared as "let y" because later was not written to<br class="">
print(y)<br class="">
<br class="">
Example Optional Binding:<br class="">
if index = myArray.indexOf("A") {<br class="">
print(index) // here it's clear that index can be "let index"<br class="">
}<br class="">
<br class="">
etc...<br class="">
<br class="">
This would _not_ mean to disallow or remove the "var and "let" mutability declarations - just to make them optional. If I still want to write it to make it clear just by reading thru the code then this is ok. But I can omit "var and "let" if I want - why bother about it at all if I can go sure that the compiler is already doing the best?<br class="">
<br class="">
Another option (if this is "too much" change) would be to just make "let" optional and "var" still should be explicitly written. So "let" would be the default and if I want mutability I have explicitly declare it as "var". This is already the rule for function parameters.<br class="">
<br class="">
Kind regards,<br class="">
Darko Damjanovic-Lichtfuss<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></blockquote></div></blockquote></div></blockquote></body></html>