<div dir="ltr">&gt; <span style="font-size:12.8px">I don&#39;t really like this specific design, though—it doesn&#39;t really match the look and feel of existing directives.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I propose that all compiler directives (that have arguments) be formatted in pseudo-function form:</span></div><div><span style="font-size:12.8px">#setline(1, file: &quot;main.swift&quot;)</span></div><div><span style="font-size:12.8px">I&#39;ll create a proposal for this, which will go hand-to-hand with my syntax for operators.<br></span></div><div><br></div><div>Additionally, I&#39;ve come up with an idea for complete operators overhaul. The main suggestions are as follows:</div><div><br></div><div>1. </div><div>All operators are available without any pre-definition:</div><div><br></div>postfix func ! &lt;T&gt;(left: T?) -&gt; T <div><br><div>func &lt;&gt;(left: Int, right: Int) -&gt; Bool  // assuming infix&lt;&gt;, no associativity, no precedence<br></div><div><br></div><div>1 ||| 2  // error: function |||(Int, Int) is not defined</div><div><br></div><div>2.</div><div>If we want to globally set associativity or precedence for infix operators, we write:</div><div><br></div><div>#operator(|||, associativity: left, precedence: 100)</div><div><br></div><div>These operator configuration directives must not be in conflict. We can omit one or both of parameters:</div><div><br></div><div>#operator(|||, precedence: 100)</div><div>#operator(|||)  // just disallow other #operator directives<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-06 14:44 GMT+03:00 Brent Royal-Gordon <span dir="ltr">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; First of all, I suggest that we remove `assignment` from Swift 2.2 in any case. It has been deprecated for long enough.<br>
&gt;<br>
&gt; Operator declarations are always global.<br>
&gt; Operator declarations of the same operator are always in conflict, even if in different modules.<br>
&gt; Therefore, I believe, operators would be best defined using directive syntax:<br>
&gt;<br>
&gt; #operator(&lt;&gt;, fixity: infix, associativity: left, precedence: 100)<br>
&gt; #operator(!, fixity: postfix)<br>
&gt;<br>
&gt; It&#39;s obvious from this declaration that it must be global and must not be duplicated even in different modules (remember C macros?).<br>
&gt; It would allow us to remove operator declaration grammar entirely, add a directive instead. Simplification of grammar and consistency is one of directions for Swift 2.2 and Swift 3.0.<br>
&gt;<br>
&gt; Why not curly braces? Curly braces in Swift declarations are used to declare multiple &quot;child&quot; entities. On the other hand, attributes and directives are used with *preudo-arguments*.<br>
&gt; I also want to remind the main difference between attributes and directives in Swift. @-attributes always stand before something and modify it. #-directives are stand-alone things on themselves.<br>
<br>
</span>Treating it as a compiler directive is an interesting idea. It certainly doesn&#39;t work anything like other declarations in Swift; a compiler directive might drive that point home.<br>
<br>
I don&#39;t really like this specific design, though—it doesn&#39;t really match the look and feel of existing directives. Looking through the Swift book, I believe the only compiler directive that actually *changes* anything is `#setline` (The Directive Formerly Known As `#line`). Its parameters consist of an unmarked list of values with no separator or labeling. Trying to duplicate that style would give us something like this:<br>
<br>
        #operator &lt;&gt; infix left 100<br>
<br>
That&#39;s, um, pretty bad. There *is* precedent for function-like constructs, though, so perhaps we could do this:<br>
<br>
        #operator &lt;&gt; infix(associativity: left, precedence: 100)<br>
        #operator ! prefix<br>
<br>
That&#39;s actually not too bad—it connects the attributes very strongly to the `infix` keyword while still putting those details at the end of the statement so they don&#39;t obscure the more important bits.<br>
<br>
One other issue is that the compiler directives which are permitted in statement position (rather than expressions like `#line` or `#available(...)`) are &quot;verb-y&quot;—they read as commands, not nouns. It would probably be more consistent to use a verb of some kind:<br>
<br>
        #addoperator &lt;&gt; infix(associativity: left, precedence: 100)<br>
        #defoperator &lt;&gt; infix(associativity: left, precedence: 100)<br>
<br>
A space would make that more readable (even if it would break consistency with `#setline`:<br>
<br>
        #add operator &lt;&gt; infix(associativity: left, precedence: 100)<br>
        #def operator &lt;&gt; infix(associativity: left, precedence: 100)<br>
<br>
Or, more fancifully:<br>
<br>
        #invent operator &lt;&gt; infix(associativity: left, precedence: 100)<br>
        #adopt operator &lt;&gt; infix(associativity: left, precedence: 100)<br>
<br>
In theory, this could become a mechanism to extend the grammar in other ways, like:<br>
<br>
        // add `foo?.bar()` to grammar<br>
        #invent dispatcher ?. infix<br>
<br>
        // add `if cond { statements } else { statements }` to grammar<br>
        #invent statement if controlflow(_: expression, _: block, else: block)<br>
<br>
But that&#39;s a whole different kind of fanciful.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div>