<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>If I may, I would like to express support for NOT making this change.</div>
<div><br>
</div>
<div>One of Swift’s really nice features is its ability to remove unnecessary syntactic cruft in cases where the context makes it possible for the compiler to infer a type or name. It’s one of Swift’s best features, and I would hate to see it chipped away. </div>
<div><br>
</div>
<div>I feel that Swift’s existing syntax is superior to the proposal to require a leading dot prefix for enum instances. The simple reasons are readability, flexibility, and brevity. Swift is already smart enough to let developers skip the tedious qualification
of enums in many cases. </div>
<div><br>
</div>
<div>If someone feels that a leading dot for enum cases inside enum implementations makes their code clearer, there is nothing stopping them from doing so, and encouraging others to follow their lead. If the vast majority of developers voluntarily started
doing so, I might even support this proposal. I don’t think they will though. </div>
<div><br>
</div>
<div>Making a dot prefix mandatory here I feel, chips away at one of Swift’s rather nice features, without a clear benefit. </div>
<div><br>
</div>
<div>In general, making things mandatory, rather than a matter of stylistic choice, is unlikely to endear the language to developers - and I’d really like to see Swift succeed in a big way.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Dr. J. Heerema</div>
<div><br>
</div>
</body>
</html>