<div dir="ltr">> <span style="font-size:12.8px">I don't really like this specific design, though—it doesn'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: "main.swift")</span></div><div><span style="font-size:12.8px">I'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'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 ! <T>(left: T?) -> T <div><br><div>func <>(left: Int, right: Int) -> Bool // assuming infix<>, 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"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> First of all, I suggest that we remove `assignment` from Swift 2.2 in any case. It has been deprecated for long enough.<br>
><br>
> Operator declarations are always global.<br>
> Operator declarations of the same operator are always in conflict, even if in different modules.<br>
> Therefore, I believe, operators would be best defined using directive syntax:<br>
><br>
> #operator(<>, fixity: infix, associativity: left, precedence: 100)<br>
> #operator(!, fixity: postfix)<br>
><br>
> It's obvious from this declaration that it must be global and must not be duplicated even in different modules (remember C macros?).<br>
> 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>
><br>
> Why not curly braces? Curly braces in Swift declarations are used to declare multiple "child" entities. On the other hand, attributes and directives are used with *preudo-arguments*.<br>
> 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't work anything like other declarations in Swift; a compiler directive might drive that point home.<br>
<br>
I don't really like this specific design, though—it doesn'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 <> infix left 100<br>
<br>
That's, um, pretty bad. There *is* precedent for function-like constructs, though, so perhaps we could do this:<br>
<br>
#operator <> infix(associativity: left, precedence: 100)<br>
#operator ! prefix<br>
<br>
That'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'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 "verb-y"—they read as commands, not nouns. It would probably be more consistent to use a verb of some kind:<br>
<br>
#addoperator <> infix(associativity: left, precedence: 100)<br>
#defoperator <> 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 <> infix(associativity: left, precedence: 100)<br>
#def operator <> infix(associativity: left, precedence: 100)<br>
<br>
Or, more fancifully:<br>
<br>
#invent operator <> infix(associativity: left, precedence: 100)<br>
#adopt operator <> 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'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>