Inline: 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger <[email protected]>:
> > Am 09.04.2016 um 19:43 schrieb Антон Жилин <[email protected]>: > [...] > > Now, I see only 1 large question/problem risen by David Waite: > Should precedence relationships be defined inside or outside of precedence > groups? > That is: should we be able to add arbitrary relationships between existing > groups? > [...] > > > I'm in favor of declaring precedence relationships inside precedencegroup > declarations. So they have a fixed place where they are defined. > I'm inclined to agree, but still not completely sure. Maybe someone else could add a vote? Chris? :) The only minor syntax issue I have is that it is not immediately clear > which operators belong to a precedence group. The former syntax with the > "members(+, -)" solved this issue. However this has (currently) an > extensibility problem: > If you define a new operator and it should belong to a precedencegroup > where you have no access to its source (like Additive) then the whole > argument about having operators in one place. > My thoughts went as follows. We should be able to add operators to existing groups, for example, defined in the Standard Library. If so, then this this statement should belong to operator, not precedence group. But we have to declare the operator anyway, so adding `: Additive` or something to the declaration does not cause huge code bloat. Especially considering operators are not defined very often. Now, we have two ways to do the same thing. External declaration is necessary and not so bad. So, following a widely known principle, I remove `members`. Another minor issue regarding your implementation of the standard library > operators: "Additive" and all "Bitwise" precedencegroups should be above > "Range" > > // so this is also possible without parentheses > (1+2) ... (3+5) > > This issue can be brought up again during another proposal which > implements this proposal. So the standard library changes *should not* > belong to this proposal (or least be clarified). > Agreed. I will edit that part to form a hierarchy that exactky matches current state of things. > > Kind regards > - Maximilian >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
