Re: [swift-evolution] [Idea] Add `bounds` function to standard library

[Karl via swift-evolution]

> On 2 Sep 2016, at 06:14, Xiaodi Wu  wrote:
> 
> Run loop modes are named by string, and as you can see in your link, 
> comparisons of run loop modes are by their raw value--i.e. by string. While 
> it's of course sensible to have a total ordering for strings, I'm skeptical 
> that you would typically want to get the "maximum" of two strings, and I'm 
> not aware of a use case for clamping a string to a range of strings.
> 
> If you're really doing that in your code, you should be aware that the 
> default ordering for String (or was it just NSString?--my memory is hazy now) 
> behaves differently on OS X and Linux, at least as of a few months ago. You 
> really should be using string-specific comparison methods (either 
> case-sensitive or not) on appropriately normalized strings, in my opinion.

I think their implementation is wrong — comparing runloop modes by their raw 
values doesn’t make sense if they are strings. But Runloop is patchy anyway, 
lots of it still lives in CoreFoundation. I was trying to draw attention to the 
concept rather than the impl.

Basically, my point is that there are other abstract types other than numbers 
which can be compared and clamped. A “priority” enum would be an example. Sure, 
you could make it RawRepresentable and compare/clamp the raw values, but that 
sounds like a workaround rather than a feature. It may be trivial to implement, 
but so are min/max themselves.

There’s obviously a line as to what should/shouldn’t be in the standard 
library. I’m not sure the line is so meandering that it includes min/max while 
excluding clamp, but it’s all a bit arbitrary anyway ¯\_(ツ)_/¯
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

[Xiaodi Wu via swift-evolution]

Run loop modes are named by string, and as you can see in your link,
comparisons of run loop modes are by their raw value--i.e. by string. While
it's of course sensible to have a total ordering for strings, I'm skeptical
that you would typically want to get the "maximum" of two strings, and I'm
not aware of a use case for clamping a string to a range of strings.

If you're really doing that in your code, you should be aware that the
default ordering for String (or was it just NSString?--my memory is hazy
now) behaves differently on OS X and Linux, at least as of a few months
ago. You really should be using string-specific comparison methods (either
case-sensitive or not) on appropriately normalized strings, in my opinion.

On Thu, Sep 1, 2016 at 10:34 PM Karl  wrote:

>
> On 31 Aug 2016, at 15:53, Xiaodi Wu  wrote:
>
> Comparable makes semantic guarantees about how values of conforming types
> might be ordered. You don't need `min` or `max` for that to be useful,
> since it's trivial to implement using comparison operators.
>
> Basic numeric types require compiler magic and thus belong in the standard
> library. Likewise, dictionaries have special syntactic sugar and have uses
> for types that can guarantee comparable semantics. A decimal type, though,
> can be implemented outside the standard library and probably would belong
> in a math library. Likewise mathematical constants such as e. I think min
> and max fall into the latter category.
>
> On Wed, Aug 31, 2016 at 8:10 AM Karl  wrote:
>
>>
>> > On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > As an additive proposal, I don't think this would be in scope for the
>> current phase of Swift 4.
>> >
>> > Looking forward, though, I'm not sure this belongs in the standard
>> library. In general, my understanding is that Swift's standard library is
>> deliberately small, and that the criteria for additions are that it's
>> widely used *and* also non-trivial for the user to write correctly. I've
>> had to use clamping, obviously, but it's a trivial one-liner that is hard
>> to write incorrectly. If anything, I'd be in favor of removing max and min
>> into a future math library outside the standard library.
>>
>> min & max (and clamping) are hardly “math” operations. They operate on
>> Comparables, so you can apply them to more abstract things than just
>> numbers.
>>
>> Otherwise, you might as well put Comparable and all standard numeric
>> types like Int and Float in a math library, too.
>
>
> Concrete example I just happened to run across: Foundation’s RunLoopMode
> conforms to Comparable. It is entirely possible that you may get a
> collection of RunLoopModes and wish to find the min/max or clamp to a
> particular mode.
>
>
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

[Karl via swift-evolution]

> On 31 Aug 2016, at 15:53, Xiaodi Wu  wrote:
> 
> Comparable makes semantic guarantees about how values of conforming types 
> might be ordered. You don't need `min` or `max` for that to be useful, since 
> it's trivial to implement using comparison operators.
> 
> Basic numeric types require compiler magic and thus belong in the standard 
> library. Likewise, dictionaries have special syntactic sugar and have uses 
> for types that can guarantee comparable semantics. A decimal type, though, 
> can be implemented outside the standard library and probably would belong in 
> a math library. Likewise mathematical constants such as e. I think min and 
> max fall into the latter category.
> 
> On Wed, Aug 31, 2016 at 8:10 AM Karl  > wrote:
> 
> > On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > As an additive proposal, I don't think this would be in scope for the 
> > current phase of Swift 4.
> >
> > Looking forward, though, I'm not sure this belongs in the standard library. 
> > In general, my understanding is that Swift's standard library is 
> > deliberately small, and that the criteria for additions are that it's 
> > widely used *and* also non-trivial for the user to write correctly. I've 
> > had to use clamping, obviously, but it's a trivial one-liner that is hard 
> > to write incorrectly. If anything, I'd be in favor of removing max and min 
> > into a future math library outside the standard library.
> 
> min & max (and clamping) are hardly “math” operations. They operate on 
> Comparables, so you can apply them to more abstract things than just numbers.
> 
> Otherwise, you might as well put Comparable and all standard numeric types 
> like Int and Float in a math library, too.

Concrete example I just happened to run across: Foundation’s RunLoopMode 
conforms to Comparable. It is entirely possible that you may get a collection 
of RunLoopModes and wish to find the min/max or clamp to a particular mode.

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeBytes

[Andrew Trick via swift-evolution]

The proposal is available here:

 
>

> On Sep 1, 2016, at 4:59 PM, Drew Crawford  wrote:
> I'm possibly one of the larger users of raw byte stuff in Swift as I maintain 
> an entire client/server network protocol stack in Swift userspace, similar in 
> spirit to one of the examples drawn out a lot longer.  Grepping my code 
> produces over 200 individual uses of unsafe byte accesses.
> 
> I definitely agree that the problem is significant enough to warrant a 
> last-minute change.
> 
> To a first approximation I agree with all the implementation choices.  The 
> naming, the choice of UInt8, length tracking, and debug-bounds checking are 
> all correct IMO.  We have been using something similar for a long time 
> internally [have you been reading my code? :-) ] so I can speak from 
> experience that the basic plan here is sound.
> 
> One thing I would like to see is an (opt-in) release-mode-bounds-check.  
> Networking is a core use case for this feature, but when you are reading from 
> a socket, production is where you need a guard against out-of-bounds UB the 
> most.  If we can't solve it for Swift 3, affected users can write a wrapper 
> to implement the boundscheck, but I think we should at very least take it up 
> again for Swift 4.
> 
> Drew

In my current implementation:
https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb
 


The bounds checks in `copyBytes(from:)` are release mode preconditions.

The bounds checks for `subscript`, `load(as:)`, and `storeBytes(of:as:)` are 
debug only because it’s likely they occur in some loop that could be covered by 
a single bounds check. By extension, the sequence iterator is only bounds 
checked in debug mode.

One possibility would be different names for the bounds checked forms of those 
methods: getByte(atOffset:), setByte(atOffset:), load(fromCheckedOffset:as:), 
storeBytes(of:toCheckedOffset:as:). Along with some kind of bounds checked 
Iterator.

I don’t think makes a lot of sense as generic Collection though. Alternatively, 
we just have an UnsafeBoundsCheckedBytes wrapper.

This would a good thing to experiment with in your project. We may be able to 
follow-up with a Swift 4 proposal. The important thing now is to determine 
whether the proposed Swift 3 design will make that wrapper difficult in any way.

-Andy
> On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution 
> (swift-evolution@swift.org ) wrote:
> 
>> I’m resending this for Review Manager Dave A. because the announce list is 
>> dropping his messages...
>> 
>> Hello Swift community,
>> 
>> The review of "UnsafeBytes" begins now and runs through September
>> 7th. This late addition to Swift 3 is a follow-up to SE-0107:
>> UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
>> allowing developers to continue working with collections of UInt8 values,
>> but now doing so via a type safe API. The UnsafeBytes API will not require 
>> direct manipulation of raw pointers or reasoning about binding memory.
>> 
>> The proposal is available here:
>> 
>>  
>> >  
>> >
>> 
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>> 
>>  > >
>> 
>> or, if you would like to keep your feedback private, directly to the
>> review manager. When replying, please try to keep the proposal link at
>> the top of the message:
>> 
>> Proposal link:
>>  > >
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift. When writing your review, here are some questions you might want to
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a
>>change to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar
>>feature, how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick
>>reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

[Douglas Gregor via swift-evolution]

> On Aug 5, 2016, at 4:32 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> SE-0112 includes the CustomNSError protocol, which includes the properties 
> errorDomain, errorCode, and errorUserInfo. These properties can be used to 
> tell Swift how to convert an error to an NSError. However, there are no 
> default implementations for errorDomain and errorCode, and there is no way to 
> access the default values for _domain and _code that Error enums get in 
> Swift. Thus, even if all one wanted to do was to provide a value for 
> NSURLErrorKey, one has to do all this:
> 
> enum MyError: CustomNSError {
>   case foo(URL)
>   case bar(URL)
>   case baz(URL)
> 
>   static var errorDomain: String {
>   return “com.MyCompany.MyApp.MyError”
>   }
> 
>   var errorCode: Int {
>   switch self {
>   case .foo(_):
>   return 1
>   case .bar(_):
>   return 2
>   case .baz(_):
>   return 3
>   }
>   }
> 
>   var errorUserInfo: [String : NSObject] {
>   // construct the actual user info
>   }
> }
> 
> Notice how far down you have to read before you finally get to the part that 
> constructs the interesting information.
> 
> PROPROSED SOLUTION:
> 
> Add default implementations for all the properties in CustomNSError.
> 
> DETAILED DESIGN:
> 
> The implementations for errorCode and errorDomain will simply provide the 
> default values of _code and _domain already provided by Swift enums. The 
> default implementation for errorUserInfo will simply return an empty 
> dictionary.
> 
> This would allow the above enum to be written simply as:
> 
> enum MyError: CustomNSError {
>   case foo(URL)
>   case bar(URL)
>   case baz(URL)
> 
>   var errorUserInfo: [String : NSObject] {
>   // construct the actual user info
>   }
> }
> 
> and the frameworks would provide something appropriate for the domain and 
> code.

The core team discussed this and will take this as an amendment to SE-0112. 
Charles, can you turn this into a pull request to update the SE-0112 document?

- Doug

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

Re: [swift-evolution] Type-annotated throws

[Douglas Gregor via swift-evolution]

> On Aug 29, 2016, at 12:14 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Aug 29, 2016, at 4:18 AM, Tino Heth via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I'm quite skeptical here (Java has already been mentioned…), but if it's 
>> done, I'd vote for removing ErrorType:
>> This empty protocol always felt a little bit odd to me, and when each 
>> function has information about what errors to expect, imho there is 
>> absolutely no benefit associated with conformance.
>> Even now, it's not that much — or does anyone actually consult a list of 
>> conforming types for error handling?
>> 
>> Tino
> 
> Error is far from empty; it appears that way, but it contains default 
> implementations to make bridging to and from Cocoa NSError objects much more 
> convenient, especially since SE-0112. Plus, it’s a protocol rather than a 
> base class, so conforming it doesn’t really constrain your design in any way.
> 
> -1 on removing Error.

Given that SE-0112 bridges *all NSError values in Objective-C* to Error, 
removing Error is a non-starter.

- Doug


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

Re: [swift-evolution] Adopting the swift evolution process in a different OSS community

[Chris Lattner via swift-evolution]

On Sep 1, 2016, at 2:09 AM, Heiko Braun via swift-evolution 
 wrote:
> I’ve been looking for a possible framework to describe a project enhancement 
> process, including the criteria and formality around that for another open 
> source community [2]. The swift evolution process seems to be very well 
> thought of a covers most of the criteria that I found to be necessary and 
> useful. 
> 
> I am wondering if it would be possible to adopt the swift evolution process 
> in a different community. I guess this question addresses the original 
> authors and copyright holders. Is this something you would support ? And if 
> you are willing to grant these rights to another community, would it make 
> sense to make it explicit through a creative commons attribution [1]?

Hi Heiko,

The Swift evolution process draws inspiration from many other projects and 
communities, which means that its ideas are probably not novel.  Further, our 
intention is for Swift and its community to make as big an impact as possible, 
so feel free to use or adapt the process as you see fit.  Several other 
communities appear to be learning from swift-evolution, and I think that’s 
great!

-Chris


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

Re: [swift-evolution] SE-0138 UnsafeBytes

[Drew Crawford via swift-evolution]

Proposal link:
 

I'm possibly one of the larger users of raw byte stuff in Swift as I maintain 
an entire client/server network protocol stack in Swift userspace, similar in 
spirit to one of the examples drawn out a lot longer.  Grepping my code 
produces over 200 individual uses of unsafe byte accesses.

I definitely agree that the problem is significant enough to warrant a 
last-minute change.

To a first approximation I agree with all the implementation choices.  The 
naming, the choice of UInt8, length tracking, and debug-bounds checking are all 
correct IMO.  We have been using something similar for a long time internally 
[have you been reading my code? :-) ] so I can speak from experience that the 
basic plan here is sound.

One thing I would like to see is an (opt-in) release-mode-bounds-check.  
Networking is a core use case for this feature, but when you are reading from a 
socket, production is where you need a guard against out-of-bounds UB the most. 
 If we can't solve it for Swift 3, affected users can write a wrapper to 
implement the boundscheck, but I think we should at very least take it up again 
for Swift 4.

Drew


On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution 
(swift-evolution@swift.org) wrote:

I’m resending this for Review Manager Dave A. because the announce list is 
dropping his messages...

Hello Swift community,

The review of "UnsafeBytes" begins now and runs through September
7th. This late addition to Swift 3 is a follow-up to SE-0107:
UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
allowing developers to continue working with collections of UInt8 values,
but now doing so via a type safe API. The UnsafeBytes API will not require 
direct manipulation of raw pointers or reasoning about binding memory.

The proposal is available here:

 


Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

 

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at
the top of the message:

Proposal link:
 

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

 * What is your evaluation of the proposal?
 * Is the problem being addressed significant enough to warrant a
   change to Swift?
 * Does this proposal fit well with the feel and direction of Swift?
 * If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?
 * How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

 

Thank you,

-Dave Abrahams
Review Manager ___
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

[swift-evolution] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to 
NSValue" begins now and runs through September 7, 2016. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reply text

Other replies
 
What
 goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

[Dave Abrahams via swift-evolution]

on Mon Aug 29 2016, Tim Vermeulen  wrote:

> The intent of my function wasn’t very clear, but it was supposed to
> return a sequence that contains *all* consecutive pairs, i.e. (0 ..<
> 4).pairs would result in [(0, 1), (1, 2), (2, 3)].

extension Sequence {
  typealias Element = Iterator.Element
  
  /// All adjacent pairs of elements, in order.
  var allAdjacentPairs: UnfoldSequence<(Element, Element), (i: Iterator, e: 
Element?)> {
var i = makeIterator()
let e = i.next()

return sequence(state: (i, e)) {
  (s: inout (i: Iterator, e: Element?))->(Element, Element)? in
  let e = s.i.next()
  defer { s.e = e }
  return e.map { (s.e!, $0) }
}
  }
}

for j in 0..<10 {
  print(Array((0..https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

[Dave Abrahams via swift-evolution]

on Mon Aug 29 2016, Tim Vermeulen  wrote:

> The intent of my function wasn’t very clear, but it was supposed to
> return a sequence that contains *all* consecutive pairs, i.e. (0 ..<
> 4).pairs would result in [(0, 1), (1, 2), (2, 3)].

extension Sequence {
  typealias Element = Iterator.Element
  
  /// All adjacent pairs of elements, in order.
  var allAdjacentPairs: UnfoldSequence<(Element, Element), (i: Iterator, e: 
Element?)> {
var i = makeIterator()
let e = i.next()

return sequence(state: (i, e)) {
  (s: inout (i: Iterator, e: Element?))->(Element, Element)? in
  let e = s.i.next()
  defer { s.e = e }
  return e.map { (s.e!, $0) }
}
  }
}

for j in 0..<10 {
  print(Array((0..https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0138 UnsafeBytes

[Andrew Trick via swift-evolution]

I’m resending this for Review Manager Dave A. because the announce list is 
dropping his messages...

Hello Swift community,

The review of "UnsafeBytes" begins now and runs through September
7th. This late addition to Swift 3 is a follow-up to SE-0107:
UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
allowing developers to continue working with collections of UInt8 values,
but now doing so via a type safe API. The UnsafeBytes API will not require 
direct manipulation of raw pointers or reasoning about binding memory.

The proposal is available here:

 
>

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

 >

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at
the top of the message:

Proposal link:
 >

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

 * What is your evaluation of the proposal?
 * Is the problem being addressed significant enough to warrant a
   change to Swift?
 * Does this proposal fit well with the feel and direction of Swift?
 * If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?
 * How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

 >

Thank you,

-Dave Abrahams
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mailing list flakiness

[Adrian Zubarev via swift-evolution]

😆 Keep it rolling.



-- 
Adrian Zubarev
Sent with Airmail

Am 1. September 2016 um 22:35:46, Jordan Rose via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hey, all. You might have noticed messages being dropped or taking a long time 
to get through on the swift.org mailing lists. The story is that the 
configuration for our outbound mail server changed on Tuesday, but we didn't 
get around to updating it until Wednesday. We think the system is just catching 
up at this point and should be back to normal by the end of the week, but we'll 
continue to investigate.

(Preemptive "this is why swift-evolution should use a forum site instead of 
mailing lists". There, now you don't have to say it.)

Sorry for the trouble,
Jordan
___
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

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

[Vladimir.S via swift-evolution]

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()) // 
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?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Mailing list flakiness

[Jordan Rose via swift-evolution]

Hey, all. You might have noticed messages being dropped or taking a long time 
to get through on the swift.org mailing lists. The story is that the 
configuration for our outbound mail server changed on Tuesday, but we didn't 
get around to updating it until Wednesday. We think the system is just catching 
up at this point and should be back to normal by the end of the week, but we'll 
continue to investigate.

(Preemptive "this is why swift-evolution should use a forum site instead of 
mailing lists". There, now you don't have to say it.)

Sorry for the trouble,
Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

[Adrian Zubarev via swift-evolution]

I’m definitely not an expert on the technical part of this but I wonder if this 
idea can be generalized.

It would be great if one could override the type A of a member from the 
supertype with type B iff there is a subtype or conformance relationship like B 
: A. I believe this would reduce the usage of associated and generic workaround 
types a lot.

As an example we could take a look at UIView where we have a variable var 
layerClass: AnyClass.

With the mentioned ability we could make it typesafe.

class UIView {
var layerClass: CALayer { … }
}

class CustomLayer : CALayer {}

class CustomView : UIView {
override var layerClass: CustomLayer { … }
}
That would be awesome. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 1. September 2016 um 05:03:15, Karl via swift-evolution 
(swift-evolution@swift.org) schrieb:


On 31 Aug 2016, at 06:10, Sitton, Yogev via swift-evolution 
 wrote:

That’s was my point.
Two sets of rules for the same case in two different places.
These should be unified.

I’ll write the proposal and create a pull request.

On Aug 17, 2016, at 11:24 PM, Slava Pestov  wrote:


On Aug 17, 2016, at 10:18 AM, Vladimir.S via swift-evolution 
 wrote:

But yes, strictly speaking 'make()->Circle?' conforms to protocol requirement 
'make()->Shape?', it does returns 'Shape?', so I believe this should be treated 
as conformance to MyShapeProtocol protocol.

I agree this should be made to work, especially since method overriding 
supports the exact same scenario.

We have two sets of rules, implemented in two different places, for matching 
method overrides and protocol witnesses. We need to unify the rules and the 
code.

Slava

Sounds like you could save yourself some trouble and just file a bug report 
instead?

___
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

[swift-evolution] Adopting the swift evolution process in a different OSS community

[Heiko Braun via swift-evolution]

I’ve been looking for a possible framework to describe a project enhancement 
process, including the criteria and formality around that for another open 
source community [2]. The swift evolution process seems to be very well thought 
of a covers most of the criteria that I found to be necessary and useful. 

I am wondering if it would be possible to adopt the swift evolution process in 
a different community. I guess this question addresses the original authors and 
copyright holders. Is this something you would support ? And if you are willing 
to grant these rights to another community, would it make sense to make it 
explicit through a creative commons attribution [1]?

Regards, Heiko


[1] https://wiki.creativecommons.org/wiki/Best_practices_for_attribution 

[2] http://microprofile.io/ 


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