[Pitch] Require parenthesis for ternary operator '?:' or change its priority


(Vladimir) #1

I'm not sure if it is a correct time to discuss this, if not - I'll hold this for later time.

I was reading the article of author of some C/C++ static code analyzer tool where he was analyzing and discussing about code of some open source program. And there was a paragraph about bugs people make when using ternary operator. There a lot of bugs in C/C++ sources of well-known open source programs(like Chromium, ReactOS, MongoDB, Unreal Engine 4, Wine, FreeBSD Kernel and many others) made when developer assumes that priority of '?:' operator is higher than other operators like '+', '*', '|', '&' and other.

Examples:

int edge_height = titlebar_bottom->height() -
     ShouldShowClientEdge() ? kClientEdgeThickness : 0;

ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;

if (IP_PACKET_SIZE < parsedPacket.info.H263.dataLength +
        parsedPacket.info.H263.insert2byteStartCode ? 2:0) {...}

stringstream ss;
ss << (sizeof(char *) == 8) ? " 64bit" : " 32bit";

return UniformVectorExpressions.GetAllocatedSize()
       + UniformScalarExpressions.GetAllocatedSize()
       + Uniform2DTextureExpressions.GetAllocatedSize()
       + UniformCubeTextureExpressions.GetAllocatedSize()
       + ParameterCollections.GetAllocatedSize()
       + UniformBufferStruct
           ?
           (sizeof(FUniformBufferStruct) +
            UniformBufferStruct->GetMembers().GetAllocatedSize())
           :
           0;

.. and so on..

Yes, in Swift we have no problem with mixing lets say Ints and Boolean values. But, it seems that it is highly possible to catch the same kind of problem with ternary operator in Swift for boolean values:

func isOne()->Bool { print(1); return false }
func isTwo()->Bool { print(2); return false }

let a = true
let b = true

let result = a || (b) ? isOne() : isTwo() // prints 1

print(result) // false

As you understand, to work correctly we need parentheses:
let result = a || ((b) ? isOne() : isTwo()) // <nothing>
print(result) // true

..or set priority of '?:' operator higher than other operators (but this probably could *silently* break old code?)

I was trying to play with custom operators and ternary operator :

func <<(lhs: inout String, rhs: String) { lhs += rhs }
func <<(lhs: inout String, rhs: Bool) { lhs += rhs.description }

let x = 10
var s = ""

s << "abc"
print(s) // abc

s << (x == 10) ? "10" : "not 10"
print(s)

.. but this crashes the compiller(bug reported), but this shows that could be other ways when ternary operator works not as expected by many developers.

I believe the problem is worth to be discussed and probably solved for Swift in near future.

Opinions?


(Vladimir) #2

(Seems my first email was not resent by mailing list due to its temporary problems. So second attempt)

I'm not sure if it is a correct time to discuss this, if not - I'll hold this for later time.

I was reading the article of author of some C/C++ static code analyzer tool where he was analyzing and discussing about code of some open source program. And there was a paragraph about bugs people make when using ternary operator. There a lot of bugs in C/C++ sources of well-known open source programs(like Chromium, ReactOS, MongoDB, Unreal Engine 4, Wine, FreeBSD Kernel and many others) made when developer assumes that priority of '?:' operator is higher than other operators like '+', '*', '|', '&' and other.

Examples:

int edge_height = titlebar_bottom->height() -
     ShouldShowClientEdge() ? kClientEdgeThickness : 0;

ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;

if (IP_PACKET_SIZE < parsedPacket.info.H263.dataLength +
        parsedPacket.info.H263.insert2byteStartCode ? 2:0) {...}

stringstream ss;
ss << (sizeof(char *) == 8) ? " 64bit" : " 32bit";

return UniformVectorExpressions.GetAllocatedSize()
       + UniformScalarExpressions.GetAllocatedSize()
       + Uniform2DTextureExpressions.GetAllocatedSize()
       + UniformCubeTextureExpressions.GetAllocatedSize()
       + ParameterCollections.GetAllocatedSize()
       + UniformBufferStruct
           ?
           (sizeof(FUniformBufferStruct) +
            UniformBufferStruct->GetMembers().GetAllocatedSize())
           :
           0;

.. and so on..

Yes, in Swift we have no problem with mixing lets say Ints and Boolean values. But, it seems that it is highly possible to catch the same kind of problem with ternary operator in Swift for boolean values:

func isOne()->Bool { print(1); return false }
func isTwo()->Bool { print(2); return false }

let a = true
let b = true

let result = a || (b) ? isOne() : isTwo() // prints 1

print(result) // false

As you understand, to work correctly we need parentheses:
let result = a || ((b) ? isOne() : isTwo()) // <nothing>
print(result) // true

..or set priority of '?:' operator higher than other operators (but this probably could *silently* break old code?)

I was trying to play with custom operators and ternary operator :

func <<(lhs: inout String, rhs: String) { lhs += rhs }
func <<(lhs: inout String, rhs: Bool) { lhs += rhs.description }

let x = 10
var s = ""

s << "abc"
print(s) // abc

s << (x == 10) ? "10" : "not 10"
print(s)

.. but this crashes the compiler(bug reported), but this shows that could be other ways when ternary operator works not as expected by many developers.

I believe the problem is worth to be discussed and probably solved for Swift in near future.

Opinions?


(Thorsten Seitz) #3

The problem you describe is not the priority of the ternary operator but that developers just assume a priority without checking (or learning) whether their assumption is correct. Changing the priority won't solve that problem, it would only shift the problem over to those developers assuming the other priority. Worse, it would create this problem for those developers knowing the correct priority, because they now have to relearn the new priority with the added difficulty of the priority being different from C.

I'm not sure whether the problem really is one (other operators have priorities too, which have to be learned), but assuming for the moment that it is, a solution would be to replace the ternary operator with an if-expression: if condition then expr1 else expr2
This would enclose the condition between two keywords and thereby be free of misunderstandings.
Replacing the ternary operator is on the commonly asked changes list, though, and therefore requires new arguments/insights why a replacement would make sense. I think the possibly confusing priority has been discussed already in the past and therefore wouldn't count as new insight, though I'm not quite sure.

-Thorsten

···

Am 03.09.2016 um 11:34 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:

(Seems my first email was not resent by mailing list due to its temporary problems. So second attempt)

I'm not sure if it is a correct time to discuss this, if not - I'll hold this for later time.

I was reading the article of author of some C/C++ static code analyzer tool where he was analyzing and discussing about code of some open source program. And there was a paragraph about bugs people make when using ternary operator. There a lot of bugs in C/C++ sources of well-known open source programs(like Chromium, ReactOS, MongoDB, Unreal Engine 4, Wine, FreeBSD Kernel and many others) made when developer assumes that priority of '?:' operator is higher than other operators like '+', '*', '|', '&' and other.

Examples:

int edge_height = titlebar_bottom->height() -
   ShouldShowClientEdge() ? kClientEdgeThickness : 0;

ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;

if (IP_PACKET_SIZE < parsedPacket.info.H263.dataLength +
      parsedPacket.info.H263.insert2byteStartCode ? 2:0) {...}

stringstream ss;
ss << (sizeof(char *) == 8) ? " 64bit" : " 32bit";

return UniformVectorExpressions.GetAllocatedSize()
     + UniformScalarExpressions.GetAllocatedSize()
     + Uniform2DTextureExpressions.GetAllocatedSize()
     + UniformCubeTextureExpressions.GetAllocatedSize()
     + ParameterCollections.GetAllocatedSize()
     + UniformBufferStruct
         ?
         (sizeof(FUniformBufferStruct) +
          UniformBufferStruct->GetMembers().GetAllocatedSize())
         :
         0;

.. and so on..

Yes, in Swift we have no problem with mixing lets say Ints and Boolean values. But, it seems that it is highly possible to catch the same kind of problem with ternary operator in Swift for boolean values:

func isOne()->Bool { print(1); return false }
func isTwo()->Bool { print(2); return false }

let a = true
let b = true

let result = a || (b) ? isOne() : isTwo() // prints 1

print(result) // false

As you understand, to work correctly we need parentheses:
let result = a || ((b) ? isOne() : isTwo()) // <nothing>
print(result) // true

..or set priority of '?:' operator higher than other operators (but this probably could *silently* break old code?)

I was trying to play with custom operators and ternary operator :

func <<(lhs: inout String, rhs: String) { lhs += rhs }
func <<(lhs: inout String, rhs: Bool) { lhs += rhs.description }

let x = 10
var s = ""

s << "abc"
print(s) // abc

s << (x == 10) ? "10" : "not 10"
print(s)

.. but this crashes the compiler(bug reported), but this shows that could be other ways when ternary operator works not as expected by many developers.

I believe the problem is worth to be discussed and probably solved for Swift in near future.

Opinions?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #4

I don't he's proposing to change the precedence of "?:" per se, just requiring — as part of its syntax — it to be enclosed in parens when it's not by itself:

x = condition ? y : z //ok, since it's by itself
x = (test || condition) ? y : z //ok, since it's still technically by itself
x = test || (condition ? y : z) //ok, has parens
x = test || condition ? y : z //syntax error, no parens

I don't actually know what the correct precedence for ?: is because I never use that 4th "form", for the very reason this change is being proposed: it's too easy for me to get mixed up otherwise.

Where was I? Oh, right, as I understand it, this doesn't so much change ?:'s precedence as it does remove it from the precedence "system".

- Dave Sweeris

···

Sent from my iPhone, without sleep.

On Sep 3, 2016, at 06:21, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

The problem you describe is not the priority of the ternary operator but that developers just assume a priority without checking (or learning) whether their assumption is correct. Changing the priority won't solve that problem, it would only shift the problem over to those developers assuming the other priority. Worse, it would create this problem for those developers knowing the correct priority, because they now have to relearn the new priority with the added difficulty of the priority being different from C.

I'm not sure whether the problem really is one (other operators have priorities too, which have to be learned), but assuming for the moment that it is, a solution would be to replace the ternary operator with an if-expression: if condition then expr1 else expr2
This would enclose the condition between two keywords and thereby be free of misunderstandings.
Replacing the ternary operator is on the commonly asked changes list, though, and therefore requires new arguments/insights why a replacement would make sense. I think the possibly confusing priority has been discussed already in the past and therefore wouldn't count as new insight, though I'm not quite sure.

-Thorsten

Am 03.09.2016 um 11:34 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:

(Seems my first email was not resent by mailing list due to its temporary problems. So second attempt)

I'm not sure if it is a correct time to discuss this, if not - I'll hold this for later time.

I was reading the article of author of some C/C++ static code analyzer tool where he was analyzing and discussing about code of some open source program. And there was a paragraph about bugs people make when using ternary operator. There a lot of bugs in C/C++ sources of well-known open source programs(like Chromium, ReactOS, MongoDB, Unreal Engine 4, Wine, FreeBSD Kernel and many others) made when developer assumes that priority of '?:' operator is higher than other operators like '+', '*', '|', '&' and other.

Examples:

int edge_height = titlebar_bottom->height() -
   ShouldShowClientEdge() ? kClientEdgeThickness : 0;

ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;

if (IP_PACKET_SIZE < parsedPacket.info.H263.dataLength +
      parsedPacket.info.H263.insert2byteStartCode ? 2:0) {...}

stringstream ss;
ss << (sizeof(char *) == 8) ? " 64bit" : " 32bit";

return UniformVectorExpressions.GetAllocatedSize()
     + UniformScalarExpressions.GetAllocatedSize()
     + Uniform2DTextureExpressions.GetAllocatedSize()
     + UniformCubeTextureExpressions.GetAllocatedSize()
     + ParameterCollections.GetAllocatedSize()
     + UniformBufferStruct
         ?
         (sizeof(FUniformBufferStruct) +
          UniformBufferStruct->GetMembers().GetAllocatedSize())
         :
         0;

.. and so on..

Yes, in Swift we have no problem with mixing lets say Ints and Boolean values. But, it seems that it is highly possible to catch the same kind of problem with ternary operator in Swift for boolean values:

func isOne()->Bool { print(1); return false }
func isTwo()->Bool { print(2); return false }

let a = true
let b = true

let result = a || (b) ? isOne() : isTwo() // prints 1

print(result) // false

As you understand, to work correctly we need parentheses:
let result = a || ((b) ? isOne() : isTwo()) // <nothing>
print(result) // true

..or set priority of '?:' operator higher than other operators (but this probably could *silently* break old code?)

I was trying to play with custom operators and ternary operator :

func <<(lhs: inout String, rhs: String) { lhs += rhs }
func <<(lhs: inout String, rhs: Bool) { lhs += rhs.description }

let x = 10
var s = ""

s << "abc"
print(s) // abc

s << (x == 10) ? "10" : "not 10"
print(s)

.. but this crashes the compiler(bug reported), but this shows that could be other ways when ternary operator works not as expected by many developers.

I believe the problem is worth to be discussed and probably solved for Swift in near future.

Opinions?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #5

With the replacement, I would prefer just "then-else", which would still
clearly carry the meaning of low priority. But yes, this option was
explicitly rejected. Unfortunately.

I also agree that changing the priority is not a solution. But how about
removing priority?

The following expression:
`s << (x == 10) ? "10" : "not 10"`
Is currently parsed as
`(s << (x == 10)) ? "10" : "not 10"`

With such a change, the compiler would make you add outer parentheses and
find a bug, by the way:
`s << ((x == 10) ? "10" : "not 10")`

Should this apply to assignment operators?
`s += (x == 10) ? "10" : "not 10" // error?`

I think such caveats of `?:` are worth creating a proposal, at least.

···

2016-09-03 14:21 GMT+03:00 Thorsten Seitz via swift-evolution < swift-evolution@swift.org>:

The problem you describe is not the priority of the ternary operator but
that developers just assume a priority without checking (or learning)
whether their assumption is correct. Changing the priority won't solve that
problem, it would only shift the problem over to those developers assuming
the other priority. Worse, it would create this problem for those
developers knowing the correct priority, because they now have to relearn
the new priority with the added difficulty of the priority being different
from C.

I'm not sure whether the problem really is one (other operators have
priorities too, which have to be learned), but assuming for the moment that
it is, a solution would be to replace the ternary operator with an
if-expression: *if* condition *then* expr1 *else* expr2
This would enclose the condition between two keywords and thereby be free
of misunderstandings.
Replacing the ternary operator is on the commonly asked changes list,
though, and therefore requires new arguments/insights why a replacement
would make sense. I think the possibly confusing priority has been
discussed already in the past and therefore wouldn't count as new insight,
though I'm not quite sure.

-Thorsten


(Thorsten Seitz) #6

I don't he's proposing to change the precedence of "?:" per se, just requiring — as part of its syntax — it to be enclosed in parens when it's not by itself:

Ah, ok, I didn't get that. That makes more sense, then :slight_smile:

-Thorsten

···

Am 03.09.2016 um 13:55 schrieb David Sweeris <davesweeris@mac.com>:

x = condition ? y : z //ok, since it's by itself
x = (test || condition) ? y : z //ok, since it's still technically by itself
x = test || (condition ? y : z) //ok, has parens
x = test || condition ? y : z //syntax error, no parens

I don't actually know what the correct precedence for ?: is because I never use that 4th "form", for the very reason this change is being proposed: it's too easy for me to get mixed up otherwise.

Where was I? Oh, right, as I understand it, this doesn't so much change ?:'s precedence as it does remove it from the precedence "system".

- Dave Sweeris

Sent from my iPhone, without sleep.

On Sep 3, 2016, at 06:21, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

The problem you describe is not the priority of the ternary operator but that developers just assume a priority without checking (or learning) whether their assumption is correct. Changing the priority won't solve that problem, it would only shift the problem over to those developers assuming the other priority. Worse, it would create this problem for those developers knowing the correct priority, because they now have to relearn the new priority with the added difficulty of the priority being different from C.

I'm not sure whether the problem really is one (other operators have priorities too, which have to be learned), but assuming for the moment that it is, a solution would be to replace the ternary operator with an if-expression: if condition then expr1 else expr2
This would enclose the condition between two keywords and thereby be free of misunderstandings.
Replacing the ternary operator is on the commonly asked changes list, though, and therefore requires new arguments/insights why a replacement would make sense. I think the possibly confusing priority has been discussed already in the past and therefore wouldn't count as new insight, though I'm not quite sure.

-Thorsten

Am 03.09.2016 um 11:34 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:

(Seems my first email was not resent by mailing list due to its temporary problems. So second attempt)

I'm not sure if it is a correct time to discuss this, if not - I'll hold this for later time.

I was reading the article of author of some C/C++ static code analyzer tool where he was analyzing and discussing about code of some open source program. And there was a paragraph about bugs people make when using ternary operator. There a lot of bugs in C/C++ sources of well-known open source programs(like Chromium, ReactOS, MongoDB, Unreal Engine 4, Wine, FreeBSD Kernel and many others) made when developer assumes that priority of '?:' operator is higher than other operators like '+', '*', '|', '&' and other.

Examples:

int edge_height = titlebar_bottom->height() -
   ShouldShowClientEdge() ? kClientEdgeThickness : 0;

ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;

if (IP_PACKET_SIZE < parsedPacket.info.H263.dataLength +
      parsedPacket.info.H263.insert2byteStartCode ? 2:0) {...}

stringstream ss;
ss << (sizeof(char *) == 8) ? " 64bit" : " 32bit";

return UniformVectorExpressions.GetAllocatedSize()
     + UniformScalarExpressions.GetAllocatedSize()
     + Uniform2DTextureExpressions.GetAllocatedSize()
     + UniformCubeTextureExpressions.GetAllocatedSize()
     + ParameterCollections.GetAllocatedSize()
     + UniformBufferStruct
         ?
         (sizeof(FUniformBufferStruct) +
          UniformBufferStruct->GetMembers().GetAllocatedSize())
         :
         0;

.. and so on..

Yes, in Swift we have no problem with mixing lets say Ints and Boolean values. But, it seems that it is highly possible to catch the same kind of problem with ternary operator in Swift for boolean values:

func isOne()->Bool { print(1); return false }
func isTwo()->Bool { print(2); return false }

let a = true
let b = true

let result = a || (b) ? isOne() : isTwo() // prints 1

print(result) // false

As you understand, to work correctly we need parentheses:
let result = a || ((b) ? isOne() : isTwo()) // <nothing>
print(result) // true

..or set priority of '?:' operator higher than other operators (but this probably could *silently* break old code?)

I was trying to play with custom operators and ternary operator :

func <<(lhs: inout String, rhs: String) { lhs += rhs }
func <<(lhs: inout String, rhs: Bool) { lhs += rhs.description }

let x = 10
var s = ""

s << "abc"
print(s) // abc

s << (x == 10) ? "10" : "not 10"
print(s)

.. but this crashes the compiler(bug reported), but this shows that could be other ways when ternary operator works not as expected by many developers.

I believe the problem is worth to be discussed and probably solved for Swift in near future.

Opinions?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #7

I agree with Thorsten. I would expand on that by arguing that (1) the
original motivation identified is inapplicable to Swift; (2) the solution
doesn't solve the problem, and creates more problems; (3) the revised
solutions are not compatible with the direction of Swift.

Argument (1):

The only real-world example provided is one in C, not Swift. The key
difference is that C will implicitly cast from many types to bool, but
Swift does not. Therefore, that example is not a demonstration of a
weakness in Swift.

The same issue could only arise in Swift when you have an expression `a
[operator] b ? c : d` where a, b, c, and d are all Bool--and the operator
is a Boolean operator. I see no evidence that confusion is encountered in
everyday practice because the user would have to (a) not know the relative
precedence of Boolean/ternary operators; (b) incorrectly believe that they
do know the relative precedence of Boolean/ternary operators; and (c)
choose not to use parentheses.

I don't think it's likely you'll encounter a real-life example of this, nor
do I think that we should make source-breaking changes to the language to
prevent that possibility, because the category of errors that are possible
if a user doesn't understand something *and* affirmatively believes
something that's not true *and* chooses not to use a sane coding style is
infinite and impossible to defend against.

Argument (2):

The original proposal is, in essence, to change `?:` to `()?:`, but that
does not solve the issue outlined above *and* silently breaks existing code
that uses the current operator correctly. For instance, `a && (b || c) ? d
: e` would have a different meaning. Unless I'm mistaken, the only way to
remove all ambiguity is to change the syntax from `?:` to `(()?:)`, which I
think you'll agree is absurd.

Argument (3):

Changing the syntax to use words is a commonly rejected proposal, and I
don't see any new information on how it would solve this particular issue.
Although custom operators can't use words, built-in ones do (e.g., `as`)
and still have relative precedence that is higher than some other
operators. Therefore, spelling out "then" absolutely does not "carry the
meaning of low priority." In fact, by moving away from C, you are now going
to raise questions for the large proportion of uses who *do* know the
precedence of ?: as to what the corresponding precedence might be in Swift.

Finally, the argument to remove precedence here has the same defect as
previous proposals on changing or removing operator precedence. This
operator, like others, does have a known precedence. It is clearly written
out in a table, and in the case of `?:` it is essentially unchanged from
other languages in the C family. If you use the operator assuming it has
precedence that it does not have, then you are in for a bad time. However,
*every* operator with a precedence relationship has this "caveat". That is,
after all, what it means to have precedence above some operator and below
some other operator. If you believe that the issues described above are
sufficient to remove precedence for `?:`, you must also believe that it is
sufficient to remove relative precedence between any two operators except
the basic arithmetic operators `+`, `-`, `*`, `/`. But this is clearly not
the direction of Swift, since we have recently changed custom operator
syntax specifically to enable a better way to define new operators *with
custom precedence*.

In short, any change in Swift should be justified by a real-world use case.
A source-breaking change, such as modifying the syntax or precedence of an
existing operator, should be justified by an overwhelming compelling
real-world use case. I see only theoretical ones presented here, and I see
no solution that actually addresses the alleged issue in a way that fits
with the direction of Swift.

···

On Sat, Sep 3, 2016 at 7:29 AM Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

With the replacement, I would prefer just "then-else", which would still
clearly carry the meaning of low priority. But yes, this option was
explicitly rejected. Unfortunately.

I also agree that changing the priority is not a solution. But how about
removing priority?

The following expression:
`s << (x == 10) ? "10" : "not 10"`
Is currently parsed as
`(s << (x == 10)) ? "10" : "not 10"`

With such a change, the compiler would make you add outer parentheses and
find a bug, by the way:
`s << ((x == 10) ? "10" : "not 10")`

Should this apply to assignment operators?
`s += (x == 10) ? "10" : "not 10" // error?`

I think such caveats of `?:` are worth creating a proposal, at least.

2016-09-03 14:21 GMT+03:00 Thorsten Seitz via swift-evolution <
swift-evolution@swift.org>:

The problem you describe is not the priority of the ternary operator but
that developers just assume a priority without checking (or learning)
whether their assumption is correct. Changing the priority won't solve that
problem, it would only shift the problem over to those developers assuming
the other priority. Worse, it would create this problem for those
developers knowing the correct priority, because they now have to relearn
the new priority with the added difficulty of the priority being different
from C.

I'm not sure whether the problem really is one (other operators have
priorities too, which have to be learned), but assuming for the moment that
it is, a solution would be to replace the ternary operator with an
if-expression: *if* condition *then* expr1 *else* expr2
This would enclose the condition between two keywords and thereby be free
of misunderstandings.
Replacing the ternary operator is on the commonly asked changes list,
though, and therefore requires new arguments/insights why a replacement
would make sense. I think the possibly confusing priority has been
discussed already in the past and therefore wouldn't count as new insight,
though I'm not quite sure.

-Thorsten

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution