<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Personally I like the current way of declaring an operator's
expected "fixity" as it reads much more naturally:<br>
<br>
infix operator += // reads "an infix operator named +="<br>
<br>
when compared to <br>
<br>
operator += (infix) <br>
// or<br>
operator += (fixity: infix) // reads as "an operator named += which
has a fixity of infix"<br>
<br>
Additionally, (pre|post|in)fix-ness of an operator has a much
greater impact on how the operator is used when compared to
associativity/precedence, and if that was designated as a behavioral
modification parameter like associativity/precedence, then it might
lead one to think that they could just alter the fixity and leave
the other attributes alone even though those attributes are only
valid for one of those fixity types:<br>
<br>
<font face="Menlo">operator +=(fixity: prefix, associativity: right,
precedence: 90, assignment: true) // compiler error!<br>
<br>
I don't like having the value of one parameter in a list control
whether other parameters are even allowed to be present, since
that as far as I'm aware isn't the case in any other aspect of
Swift.</font><br>
<br>
On 3/6/2016 12:51 AM, T.J. Usiyan via swift-evolution wrote:<br>
<blockquote
cite="mid:CAGJeWTorq0hA_b97Kgx1M_3vLbxwo7a1W3FuP8A=oe8kZXgA2w@mail.gmail.com"
type="cite">
<div dir="ltr">I'm not completely sold on the proposed change but,
if we were to do something like this, I suggest we include
`fixity` as a parameter and come up with something for
`assignment` (`true` in my example is admittedly suboptimal ).
Those `operator -(prefix) seems strange to me.
<div><br>
</div>
<div>```</div>
<div>
<div style="font-size:13px"><font face="Menlo">operator
+=(fixity: infix, associativity: right, precedence: 90,
assignment: true) </font></div>
<div style="font-size:13px"><font face="Menlo">operator
-(fixity: prefix)</font></div>
<div style="font-size:13px"><font face="Menlo">operator
!(fixity: postfix)</font></div>
</div>
<div>```</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Mar 6, 2016 at 12:35 AM, Erica
Sadun via swift-evolution <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:swift-evolution@swift.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>I like this approach too BUT my only concern is how
long it takes to get to the actual name. </div>
<div>I know I probably hate this already (give me time to
sleep on it) and I'm not wedded to the </div>
<div>approach, but I'd like to see the operator move left
for readability so that it's more like a </div>
<div>func declaration:</div>
<div><br>
</div>
<div>
<div><font face="Menlo">operator +=(infix,
associativity: right, precedence: 90, assignment) </font></div>
<div><font face="Menlo">operator -(prefix)</font></div>
<div><font face="Menlo">operator !(postfix)</font></div>
</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-- E</div>
</font></span>
<div>
<div class="h5">
<div><br>
</div>
<div>
<blockquote type="cite">
<div>On Mar 5, 2016, at 10:24 PM, Brent
Royal-Gordon via swift-evolution <<a
moz-do-not-send="true"
href="mailto:swift-evolution@swift.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></a>>
wrote:</div>
<br>
<div>
<div>
<blockquote type="cite">infix operator += {
associativity: right, precedence: 90,
assignment: true }<br>
</blockquote>
<br>
I'm a little uncomfortable putting what looks
for all the world like a parameter list into
curly brackets; it just doesn't feel in step
with other declarations. (To be fair, I wasn't
comfortable with the old way, either.)<br>
<br>
Here's what I suggest. Usually, a bunch of
parameters modifying a declaration would go in
a parenthesized list after the particular
keyword they modified, and in this case,
`associativity` and `precedence` (and probably
`assignment` too, though I don't know for sure
since it's not documented) are only valid on
an infix operator. That would suggest:<br>
<br>
<span style="white-space:pre-wrap"> </span>infix(associativity:
right, precedence: 90, assignment) operator +=<br>
<span style="white-space:pre-wrap"> </span>prefix
operator -<br>
<span style="white-space:pre-wrap"> </span>postfix
operator !<br>
<br>
-- <br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a moz-do-not-send="true"
href="mailto:swift-evolution@swift.org"
target="_blank">swift-evolution@swift.org</a><br>
<a moz-do-not-send="true"
href="https://lists.swift.org/mailman/listinfo/swift-evolution"
target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a moz-do-not-send="true"
href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a moz-do-not-send="true"
href="https://lists.swift.org/mailman/listinfo/swift-evolution"
rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
swift-evolution mailing list
<a class="moz-txt-link-abbreviated" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>
<a class="moz-txt-link-freetext" href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
</pre>
</blockquote>
<br>
</body>
</html>