Regards
LM
(From mobile)
On Jun 28, 2016, at 6:32 PM, John McCall wrote:
>> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic
>> wrote:
>>
>> Question inline
>> Regards
>> LM
>> (From mobile)
>> On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution
>> wrote:
>>
On Jun 25, 2016, at 10
I did not change 'precedencegroup', but still strongly vote for
'precedence', despite counter-arguments.
But there is a problem besides bikeshedding that we need to solve. We have
the following groups:
Assignment
Ternary
Default
LogicalOr
LogicalAnd
Comparative
NilCoalescing
Cast
Range
Additive
on Thu Jun 23 2016, Xiaodi Wu wrote:
> On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Proposal link:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>>
>> Hello Swift Community,
>>
>> The re
> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic
> wrote:
>
> Question inline
> Regards
> LM
> (From mobile)
> On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution
> wrote:
>
>>> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution
>>> wrote:
>>> I replaced `precedencegroup` w
Question inline
Regards
LM
(From mobile)
On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution
wrote:
>> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution
>> wrote:
>> I replaced `precedencegroup` with `precedence` and added `Precedence`
>> suffix to all precedence group n
I'm just concerned that precedencegroup might be confusing at first look.
But like you said, it's not going to be a widely written feature (but it's will
be widely used!).
Also, is taking a keyword at the top level really that bad? Precedence could
still be used inside classes and methods etc
> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution
> wrote:
> I replaced `precedencegroup` with `precedence` and added `Precedence`
> suffix to all precedence group names. See:
>
> https://github.com/Anton3/swift-evolution/blob/fix-operator-
> precedence/proposals/0077-operator-pr
L. Mihalkovic via swift-evolution writes:
> Don't you think that for no other reason than completeness it would make
sense to document the metacircular
> definition I suggested?
Okay, okay, I will.
___
swift-evolution mailing list
swift-evolution@swi
Don't you think that for no other reason than completeness it would make sense
to document the metacircular definition I suggested?
> On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution
> wrote:
>
> I replaced `precedencegroup` with `precedence` and added `Precedence`
> suffix to a
I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:
https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md
My feelings:
1. `precedencegroup` describes what it declares more precise
Yes!
On Sat, Jun 25, 2016 at 11:33 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
> Xiaodi Wu via swift-evolution writes:
>
> > I mean, we have `protocol IteratorProtocol`, so this is par for the
> course!
> > precedencegroup RangePrecedence { ... }
>
> Brandon sent me a bri
Xiaodi Wu via swift-evolution writes:
> I mean, we have `protocol IteratorProtocol`, so this is par for the
course!
> precedencegroup RangePrecedence { ... }
Brandon sent me a bright idea: we should rename precedencegroup to
precedence. Compare:
precedence RangePrecedence { ... }
protocol Ite
I mean, we have `protocol IteratorProtocol`, so this is par for the course!
On Sat, Jun 25, 2016 at 09:46 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
> From the rationale follows that by default, we get the following
> precedence group declarations:
>
> precedencegroup R
From the rationale follows that by default, we get the following
precedence group declarations:
precedencegroup RangePrecedence { ... }
Everyone agrees? Any ideas on how to reduce redundancy without adding name
conflicts?
___
swift-evolution mailing
Swift is all about values and protocols, so I was thinking about smthg like
this:
enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
casedefaultGroup(OperatorAssociativity)
indirect case strongerThan(OperatorAssociativity,PrecedenceGroup)
indirect case weakerThan(O
L. Mihalkovic via swift-evolution writes:
> > Could you please explain what you mean by "meta-circular syntax for
the
> > precedence group definitions"? An example?
> =define it using existing swift constructs rather than by extending
swift with new kwd looks like grp
> matches a struct.
I s
Inline
Regards
(From mobile)
> On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution
> wrote:
>
> L. Mihalkovic via swift-evolution writes:
>
>> Has a meta-circular syntax been considered for the precedence group
> definitions? Aside from limiting the
>> proliferation of new keywords,
L. Mihalkovic via swift-evolution writes:
> Has a meta-circular syntax been considered for the precedence group
definitions? Aside from limiting the
> proliferation of new keywords, it would also make them discoverable by
reflection when the api gets added
> in 4.0. My apologies if it was alrea
Has a meta-circular syntax been considered for the precedence group
definitions? Aside from limiting the proliferation of new keywords, it would
also make them discoverable by reflection when the api gets added in 4.0. My
apologies if it was already discarded.
Regards
LM
(From mobile)
> On Jun
> On 23 juin 2016, at 09:32, Anton Zhilin via swift-evolution
> wrote:
>
> Ross O'Brien via swift-evolution writes:
>
>> The naming suggestion: why not simply 'precedes' and 'succeeds'? This
> avoids the conjoined words problem. Then you're just writing
> 'Multiplication { succeeds: Exponen
If we chose something other than strongerThan and weakerThan, I would
really like to see something like
evaluateBefore, evaluateAfter
foundBefore, foundAfter
lookupBefore, lookupAfter
On Thu, Jun 23, 2016 at 11:32 AM, Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
> Ross
Ross O'Brien via swift-evolution writes:
> The naming suggestion: why not simply 'precedes' and 'succeeds'? This
avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.
I still believe that `above` and `below` are clearer.
I've got another suggestion for the bike shedding, and a question.
The naming suggestion: why not simply 'precedes' and 'succeeds'? This
avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.
The question: this syntax lets y
> On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution
> wrote:
>
> 1. I've revised the proposal to mostly meet the recommendations.
Thanks continuing to push this forward! I’m really looking forward to this
change and hope the revision is met with acceptance.
>
> https://github.
1. I've revised the proposal to mostly meet the recommendations.
https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
operator-precedence.md
2. My reaction to the rationale:
precedencegroup Foo {
associativity: left
strongerThan: Bar
weakerThan: Bas
}
I agree with colons,
I agree that the colon-separated syntax looks cleaner. However, I agree
with Xiaodi about the stronger/weaker terms being less clear (if only
because I associate those terms with memory management in Swift, not
operator precedence). My personal preference would be for something like
'appliedBefore'
On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Hello Swift Community,
>
> The review of SE-0077: "Improved operator declarations" r
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
Hello Swift Community,
The review of SE-0077: "Improved operator declarations" ran from May 17...23.
On June 22, 2016, the core team decided to return the first version of this
proposal fo
28 matches
Mail list logo
