Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Susan Cheng via swift-evolution]

Here are two problems being fixed.

First, considering the example:

struct MyRawDataStruct {

  var size: UInt32
  var signature: UInt32
  var width: UInt32
  var height: UInt32
}

The type UInt32 doesn't tall us the endianness of the value. Also, if we read 
the value of it, the value is being byte-swapped when endianness is not 
matching with the system.

This causes us have to manual convert the value from/to correct endianness.

struct MyRawDataStruct {

  var size: BEInteger
  var signature: BEInteger
  var width: BEInteger
  var height: BEInteger
}

So, my proposal fix the problem. We can easily to get the value.

let header: MyRawDataStruct = data.withUnsafePointer { $0.pointee }

print(header.size)  // print the representing value

Second, it's misleading means of bigEndian and littleEndian from 
FixedWidthInteger

if we do this

let a = 1

print(a.bigEndian.bigEndian)

It's just swap bytes twice but not converting value to big-endian

My proposal solves the problem

let b = a.bigEndian   //BEInteger

b.bigEndian// remain big-endian of a

> Max Moiseev  於 2017年7月8日 上午1:48 寫道：
> 
> Hi Susan,
> 
> Was there any motivation for this proposal that I missed? If not then, can 
> you please provide it in a few sentences? Otherwise it’s not clear to me what 
> problem it is supposed to fix.
> 
> Thanks,
> Max 
> 
> 
>> On Jul 6, 2017, at 8:21 PM, Susan Cheng via swift-evolution 
>>  wrote:
>> 
>> IMO, it has unclear representation when FixedWidthInteger working with 
>> endianness specific type.
>> 
>> so I want to introduce the endianness specific wrapper:
>> 
>> public struct BEInteger : FixedWidthInteger {
>> 
>> public var bigEndian: BEInteger { get }
>> 
>> public var littleEndian: LEInteger { get }
>> }
>> 
>> public struct LEInteger : FixedWidthInteger {
>> 
>> public var bigEndian: BEInteger { get }
>> 
>> public var littleEndian: LEInteger { get }
>> }
>> 
>> also, we should change the FixedWidthInteger as follow:
>> 
>> public protocol FixedWidthInteger : BinaryInteger {
>> 
>> /// deprecated, we should use value.bigEndian instead
>> init(bigEndian value: Self)
>> 
>> /// deprecated, we should use value.littleEndian instead
>> init(littleEndian value: Self)
>> 
>> associatedtype EndianRepresentingValue : FixedWidthInteger
>> 
>> var bigEndian: BEInteger { get }
>> 
>> var littleEndian: LEInteger { get }
>> }
>> 
>> =
>> 
>> this is my working alternative implementation:
>> 
>> 
>> @_versioned
>> protocol EndianInteger : FixedWidthInteger {
>> 
>> associatedtype BitPattern : FixedWidthInteger
>> 
>> associatedtype RepresentingValue : FixedWidthInteger
>> 
>> var bitPattern: BitPattern { get }
>> 
>> init(bitPattern: BitPattern)
>> 
>> var representingValue : RepresentingValue { get set }
>> 
>> init(representingValue: RepresentingValue)
>> }
>> 
>> extension EndianInteger {
>> 
>> @_transparent
>> public init(integerLiteral value: RepresentingValue.IntegerLiteralType) {
>> self.init(representingValue: RepresentingValue(integerLiteral: 
>> value))
>> }
>> 
>> @_transparent
>> public init?(exactly source: T) where T : BinaryInteger {
>> guard let value = RepresentingValue(exactly: source) else { return 
>> nil }
>> self.init(representingValue: value)
>> }
>> 
>> @_transparent
>> public init?(exactly source: T) where T : FloatingPoint {
>> guard let value = RepresentingValue(exactly: source) else { return 
>> nil }
>> self.init(representingValue: value)
>> }
>> 
>> @_transparent
>> public init(_ value: RepresentingValue) {
>> self.init(representingValue: value)
>> }
>> 
>> @_transparent
>> public init(_ source: T) where T : FloatingPoint {
>> self.init(representingValue: RepresentingValue(source))
>> }
>> 
>> @_transparent
>> public init(_ source: T) where T : BinaryInteger {
>> self.init(representingValue: RepresentingValue(source))
>> }
>> 
>> @_transparent
>> public init(extendingOrTruncating source: T) where T : BinaryInteger {
>> self.init(representingValue: 
>> RepresentingValue(extendingOrTruncating: source))
>> }
>> 
>> @_transparent
>> public init(clamping source: T) where T : BinaryInteger {
>> self.init(representingValue: RepresentingValue(clamping: source))
>> }
>> 
>> @_transparent
>> public init(_truncatingBits bits: UInt) {
>> self.init(representingValue: RepresentingValue(_truncatingBits: 
>> bits))
>> }
>> }
>> 
>> extension EndianInteger {
>> 
>> @_transparent
>> public static var isSigned: Bool {
>> return RepresentingValue.isSigned
>> }
>> 
>> @_transparent
>> public 

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Dave Abrahams via swift-evolution]

on Thu Jul 06 2017, Brent Royal-Gordon  wrote:

>> On Jul 6, 2017, at 9:13 AM, Dave Abrahams  wrote:
>> 
>> I'm not sure what you're objecting to about this.  Is it the very
>> appearance of curly braces?
>
> I went to bed thinking that maybe I should have explained that better,
> and I guess I was right. ;^) Here's why I think we should do something
> here.
>
> From what I can tell, mapping or filtering on a single property is
> exceptionally common. I ran a few regexes on the Swift code present on
> my machine (basically the stuff in the Swift repos, plus my
> open-source projects, plus my closed-source stuff, plus various
> playgrounds and things) to see how common different kinds of `map`,
> `filter`, and `flatMap` closures were:
>
>   2142OP { …$0… }
>   1835OP(function) or OP(some.method)
>   589 OP { $0.property } or OP { $0.some.property }
>   564 OP { $0.property }
>   525 OP { function(…$0…) } or OP { some.method(…$0…) }
>   186 OP { $0.method(…) }
>   153 OP { function($0) } or OP { some.method($0) }
>   100 OP { $0 as SomeType } or OP { $0 as? SomeType } or OP { 
> $0 as! SomeType }
>   52  OP { $0.method() }
>   35  OP { collection[…$0…] } or OP { some.collection[…$0…] }
>   20  OP { collection[$0] } or OP { some.collection[$0] }
>   13  OP { $0! }
>
> (Simple regex-based match of `map`, `flatMap`, and `filter`
> calls. Permits various spacing schemes and `try`. If you want to run
> it on a more representative sample, the script is here, requires
> fish(1):
> https://gist.github.com/brentdax/2a8ee2705c39e9948aafedbd81b1366f)
>
> So, at least in my unscientific sample, more than a quarter of
> map/filter/flatMap calls which use `$0` simply look up a property or
> chain of properties on it. 

Totally believable.

> If we want to make something about `map`
> and friends more convenient, this seems like a good place to look.
>
> (Using a straight function is a few times more common than a property,
> but given that this is also the syntax used to abstract over a closure
> body, I'm not sure how much weight to put on that fact.)
>
> So what's wrong with what we have now? Syntactic weight. Consider this 
> expression:
>
>   person.map { $0.name }
>
> The "loudest" parts of this expression are the closure brackets and
> the `$0`, but they are actually the *least* important. 

That's funny, my eye skips right over them and focuses on “.name” Not
kidding at all.  And “name” is a single fairly short, un-chained
identifier.

> They do not express anything about what this line of code *does*; they
> exist solely to tell the compiler how to do it. They are pure glue
> code, and serve only to obscure the actual intent. Compare that to:
>
>   person.map(\.name)
>
> Here, we still have a glue character (the `\`), but it's just one, and
> it's relatively inconspicuous compared to something like `$0`.

Meh.  This in particular doesn't look like a major improvement.

> That's not *too* bad, though. It gets a lot worse when the key path is
> actually in a variable:
>
>   array.map { $0[keyPath: prop] }

> Again, look at how much of this line is given over to adapting a line
> of code to the compiler—and how little that actually matters when
> understanding what the line does. The most important thing in that
> expression is `prop`, but it's completely lost in this sea of
> irrelevant syntax. Compare to:
>
>   array.map(prop)

Yes, that's a lot of extra syntax.  But again, you've used an
abbreviated, single identifier for the property and a
short, non-descriptive identifier for the array.  Let's make this a
fair/realistic comparison:

gradeHistories.map { $0[keyPath: \.average] }

vs.
gradeHistories.map(\.average)


Yep, I agree that passing a keypath directly is still much nicer in this
case.

> Which puts that piece of information front and center.
>
> If there was an argument that the case was too complex to handle
> nicely, I think we could justify leaving it alone. 

It's not the “too complex” criterion I'd want to talk about—it's the
“how often do you need it” criterion.  If it's rare, it doesn't matter
so much (I don't have an opinion about whether it is in fact rare).

> That's essentially what happened with the much-requested placeholder
> syntax:

Sorry, I may have missed that discussion.

> Lots of people wanted it, but critics pointed out the fundamental
> ambiguity of the syntax, and after spending gallons of electrons
> arguing about it, the proponents pretty much backed off. But key paths
> don't have that problem—they always work the same way and are
> completely unambiguous, so there's no scope for misinterpretation. And
> the cases key paths can handle appear to be about as common as the
> cases placeholder syntax was intended for.
>
>
> Nor is there a strong argument 

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Hooman Mehr via swift-evolution]

Considering these observations and more from Brent and Dave, I support 
ultimately making KeyPath) a subtype of (T)->U as suggested.

If someone really wants this now, I would go with a prefix operator as a 
stopgap:

prefix operator ~

prefix func ~(lhs: KeyPath) -> (T)->U { return { $0[keyPath: lhs] } }

struct Guy { let name: String }

let guys = [
Guy(name: "Benjamin"),
Guy(name: "Dave"),
Guy(name: "Brent"),
Guy(name: "Max")
]

guys.map(~\.name)


> On Jul 7, 2017, at 11:15 AM, Max Moiseev via swift-evolution 
>  wrote:
> 
> A few more observations not necessarily supporting either side:
> 
> - Why only map, flatMap, and filter? drop, prefix, and sorted can also 
> benefit from keyPaths.
> - Adding these overloads only to Sequence will have a very interesting side 
> effect on code like: xs.lazy.map(\.name), because lazy. Therefore all these 
> overloads will have to be duplicated everywhere.
> - Naive implementation (the one that simply calls the closure taking 
> overload) was 4 times slower when I quickly tested it. On the positive side 
> though, this same naive implementation does not have to be a part of standard 
> library and can easily be provided by a third-party package...
> 
> Max
>> On Jul 5, 2017, at 10:08 AM, Benjamin Herzog via swift-evolution 
>> > wrote:
>> 
>> Hey guys,
>> 
>> I would like to pitch a small convenient change to the Swift stdlib. With 
>> KeyPaths added in SE-0161 I would like to add some convenience calls to map, 
>> flatMap and filter in Sequences. To extract properties of an array of 
>> objects we currently use trailing closure syntax together with the shorthand 
>> $0 for the first closure argument. This is still kind of verbose and also 
>> hard to read in some situations.
>> I think it is much better to understand what is going on when using the type 
>> safe KeyPaths for that. I already implemented a working solution and would 
>> like to pitch the idea here to get some feedback before opening the swift 
>> evolution proposal.
>> I propose using 
>> 
>> persons.flatMap(keyPath: \.name)
>> 
>> over
>> 
>> persons.flatMap { $0.name }
>> 
>> Link to pull request: https://github.com/apple/swift/pull/10760 
>> 
>> 
>> Link to proposal draft: 
>> https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md
>>  
>> 
>> 
>> Thanks in advance for your feedback!
>> __
>> 
>> Benjamin Herzog
>> 
>> ___
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Guard/Catch

[Dave DeLong via swift-evolution]

What about the situation where you have:

func doSomething() throws → Result? { … }

How would you handle both the catch and the let binding of the result?

Dave

> On Jul 7, 2017, at 7:55 AM, Elviro Rocca via swift-evolution 
>  wrote:
> 
> Amazing proposal, I love it and thinking back there's plenty of times where I 
> would have used the guard-catch instead of the non-swifty (to me) do-catch. A 
> guard-catch construct still allows to handle errors explicitly, with the 
> added convenience of forcing a return inside the catch, which is basically 
> 100% of the cases for me. It's consistent with the semantics of "guard", that 
> is, instead of indenting, exit the scope in the "negative" case.
> 
> I do not agree in mixing guard-catch with optional binding (+ bool 
> conditions). I think it's clearer to keep the two separated, since you can 
> always:
> 
> guard let x = try throwingFunction() catch { ... }
> guard let y = x.optionalProperty, y == 42 else { ... }
> 
> 
> Thanks
> 
> 
> Elviro
> 
>> Il giorno 05 lug 2017, alle ore 19:40, Soroush Khanlou via swift-evolution 
>> > ha scritto:
>> 
>> I’d like to propose a guard/catch construct to the language. It would allow 
>> code to use throwing functions and handle errors fully, without straying 
>> from a happy path. do/catch can be a bit heavy-handed sometimes, and it 
>> would be nice to be able to handle throwing functions without committing to 
>> all the nesting and ceremony of do/catch.
>> 
>> Full proposal, which discusses all the corner cases and alternatives:
>> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
>> 
>> 
>> Looking forward to feedback!
>> 
>> Soroush
>> ___
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Max Moiseev via swift-evolution]

A few more observations not necessarily supporting either side:

- Why only map, flatMap, and filter? drop, prefix, and sorted can also benefit 
from keyPaths.
- Adding these overloads only to Sequence will have a very interesting side 
effect on code like: xs.lazy.map(\.name), because lazy. Therefore all these 
overloads will have to be duplicated everywhere.
- Naive implementation (the one that simply calls the closure taking overload) 
was 4 times slower when I quickly tested it. On the positive side though, this 
same naive implementation does not have to be a part of standard library and 
can easily be provided by a third-party package...

Max
> On Jul 5, 2017, at 10:08 AM, Benjamin Herzog via swift-evolution 
>  wrote:
> 
> Hey guys,
> 
> I would like to pitch a small convenient change to the Swift stdlib. With 
> KeyPaths added in SE-0161 I would like to add some convenience calls to map, 
> flatMap and filter in Sequences. To extract properties of an array of objects 
> we currently use trailing closure syntax together with the shorthand $0 for 
> the first closure argument. This is still kind of verbose and also hard to 
> read in some situations.
> I think it is much better to understand what is going on when using the type 
> safe KeyPaths for that. I already implemented a working solution and would 
> like to pitch the idea here to get some feedback before opening the swift 
> evolution proposal.
> I propose using 
> 
> persons.flatMap(keyPath: \.name)
> 
> over
> 
> persons.flatMap { $0.name }
> 
> Link to pull request: https://github.com/apple/swift/pull/10760 
> 
> 
> Link to proposal draft: 
> https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md
>  
> 
> 
> Thanks in advance for your feedback!
> __
> 
> Benjamin Herzog
> 
> ___
> 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

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Max Moiseev via swift-evolution]

Hi Susan,

Was there any motivation for this proposal that I missed? If not then, can you 
please provide it in a few sentences? Otherwise it’s not clear to me what 
problem it is supposed to fix.

Thanks,
Max 


> On Jul 6, 2017, at 8:21 PM, Susan Cheng via swift-evolution 
>  wrote:
> 
> IMO, it has unclear representation when FixedWidthInteger working with 
> endianness specific type.
> 
> so I want to introduce the endianness specific wrapper:
> 
> public struct BEInteger : FixedWidthInteger {
> 
> public var bigEndian: BEInteger { get }
> 
> public var littleEndian: LEInteger { get }
> }
> 
> public struct LEInteger : FixedWidthInteger {
> 
> public var bigEndian: BEInteger { get }
> 
> public var littleEndian: LEInteger { get }
> }
> 
> also, we should change the FixedWidthInteger as follow:
> 
> public protocol FixedWidthInteger : BinaryInteger {
> 
> /// deprecated, we should use value.bigEndian instead
> init(bigEndian value: Self)
> 
> /// deprecated, we should use value.littleEndian instead
> init(littleEndian value: Self)
> 
> associatedtype EndianRepresentingValue : FixedWidthInteger
> 
> var bigEndian: BEInteger { get }
> 
> var littleEndian: LEInteger { get }
> }
> 
> =
> 
> this is my working alternative implementation:
> 
> 
> @_versioned
> protocol EndianInteger : FixedWidthInteger {
> 
> associatedtype BitPattern : FixedWidthInteger
> 
> associatedtype RepresentingValue : FixedWidthInteger
> 
> var bitPattern: BitPattern { get }
> 
> init(bitPattern: BitPattern)
> 
> var representingValue : RepresentingValue { get set }
> 
> init(representingValue: RepresentingValue)
> }
> 
> extension EndianInteger {
> 
> @_transparent
> public init(integerLiteral value: RepresentingValue.IntegerLiteralType) {
> self.init(representingValue: RepresentingValue(integerLiteral: value))
> }
> 
> @_transparent
> public init?(exactly source: T) where T : BinaryInteger {
> guard let value = RepresentingValue(exactly: source) else { return 
> nil }
> self.init(representingValue: value)
> }
> 
> @_transparent
> public init?(exactly source: T) where T : FloatingPoint {
> guard let value = RepresentingValue(exactly: source) else { return 
> nil }
> self.init(representingValue: value)
> }
> 
> @_transparent
> public init(_ value: RepresentingValue) {
> self.init(representingValue: value)
> }
> 
> @_transparent
> public init(_ source: T) where T : FloatingPoint {
> self.init(representingValue: RepresentingValue(source))
> }
> 
> @_transparent
> public init(_ source: T) where T : BinaryInteger {
> self.init(representingValue: RepresentingValue(source))
> }
> 
> @_transparent
> public init(extendingOrTruncating source: T) where T : BinaryInteger {
> self.init(representingValue: RepresentingValue(extendingOrTruncating: 
> source))
> }
> 
> @_transparent
> public init(clamping source: T) where T : BinaryInteger {
> self.init(representingValue: RepresentingValue(clamping: source))
> }
> 
> @_transparent
> public init(_truncatingBits bits: UInt) {
> self.init(representingValue: RepresentingValue(_truncatingBits: bits))
> }
> }
> 
> extension EndianInteger {
> 
> @_transparent
> public static var isSigned: Bool {
> return RepresentingValue.isSigned
> }
> 
> @_transparent
> public static var bitWidth: Int {
> return RepresentingValue.bitWidth
> }
> 
> @_transparent
> public static var max: Self {
> return Self(representingValue: RepresentingValue.max)
> }
> 
> @_transparent
> public static var min: Self {
> return Self(representingValue: RepresentingValue.min)
> }
> }
> 
> extension EndianInteger {
> 
> @_transparent
> public var hashValue: Int {
> return representingValue.hashValue
> }
> 
> @_transparent
> public var description: String {
> return representingValue.description
> }
> 
> @_transparent
> public var bitWidth: Int {
> return representingValue.bitWidth
> }
> 
> @_transparent
> public var magnitude: RepresentingValue.Magnitude {
> return representingValue.magnitude
> }
> 
> @_transparent
> public var trailingZeroBitCount: Int {
> return representingValue.trailingZeroBitCount
> }
> 
> @_transparent
> public var nonzeroBitCount: Int {
> return representingValue.nonzeroBitCount
> }
> 
> @_transparent
> public var leadingZeroBitCount: Int {
> return representingValue.leadingZeroBitCount
> }
> 
> @_transparent
> public var byteSwapped: Self 

[swift-evolution] [Proposal] Introduces endianness specific type

[Susan Cheng Team Garment via swift-evolution]

IMO, it has unclear representation when FixedWidthInteger working with
endianness specific type.


so I want to introduce the endianness specific wrapper:


public struct BEInteger : FixedWidthInteger {



public var bigEndian: BEInteger { get }



public var littleEndian: LEInteger { get }

}


public struct LEInteger : FixedWidthInteger {



public var bigEndian: BEInteger { get }



public var littleEndian: LEInteger { get }

}


also, we should change the FixedWidthInteger as follow:


public protocol FixedWidthInteger : BinaryInteger {



/// deprecated, we should use value.bigEndian instead

init(bigEndian value: Self)



/// deprecated, we should use value.littleEndian instead

init(littleEndian value: Self)



associatedtype EndianRepresentingValue : FixedWidthInteger



var bigEndian: BEInteger { get }



var littleEndian: LEInteger { get }

}

=


this is my working alternative implementation:



@_versioned

protocol EndianInteger : FixedWidthInteger {



associatedtype BitPattern : FixedWidthInteger



associatedtype RepresentingValue : FixedWidthInteger



var bitPattern: BitPattern { get }



init(bitPattern: BitPattern)



var representingValue : RepresentingValue { get set }



init(representingValue: RepresentingValue)

}


extension EndianInteger {



@_transparent

public init(integerLiteral value: RepresentingValue.IntegerLiteralType)
{

self.init(representingValue: RepresentingValue(integerLiteral:
value))

}



@_transparent

public init?(exactly source: T) where T : BinaryInteger {

guard let value = RepresentingValue(exactly: source) else { return
nil }

self.init(representingValue: value)

}



@_transparent

public init?(exactly source: T) where T : FloatingPoint {

guard let value = RepresentingValue(exactly: source) else { return
nil }

self.init(representingValue: value)

}



@_transparent

public init(_ value: RepresentingValue) {

self.init(representingValue: value)

}



@_transparent

public init(_ source: T) where T : FloatingPoint {

self.init(representingValue: RepresentingValue(source))

}



@_transparent

public init(_ source: T) where T : BinaryInteger {

self.init(representingValue: RepresentingValue(source))

}



@_transparent

public init(extendingOrTruncating source: T) where T : BinaryInteger
{

self.init(representingValue:
RepresentingValue(extendingOrTruncating: source))

}



@_transparent

public init(clamping source: T) where T : BinaryInteger {

self.init(representingValue: RepresentingValue(clamping: source))

}



@_transparent

public init(_truncatingBits bits: UInt) {

self.init(representingValue: RepresentingValue(_truncatingBits:
bits))

}

}


extension EndianInteger {



@_transparent

public static var isSigned: Bool {

return RepresentingValue.isSigned

}



@_transparent

public static var bitWidth: Int {

return RepresentingValue.bitWidth

}



@_transparent

public static var max: Self {

return Self(representingValue: RepresentingValue.max)

}



@_transparent

public static var min: Self {

return Self(representingValue: RepresentingValue.min)

}

}


extension EndianInteger {



@_transparent

public var hashValue: Int {

return representingValue.hashValue

}



@_transparent

public var description: String {

return representingValue.description

}



@_transparent

public var bitWidth: Int {

return representingValue.bitWidth

}



@_transparent

public var magnitude: RepresentingValue.Magnitude {

return representingValue.magnitude

}



@_transparent

public var trailingZeroBitCount: Int {

return representingValue.trailingZeroBitCount

}



@_transparent

public var nonzeroBitCount: Int {

return representingValue.nonzeroBitCount

}



@_transparent

public var leadingZeroBitCount: Int {

return representingValue.leadingZeroBitCount

}



@_transparent

public var byteSwapped: Self {

return Self(representingValue: representingValue.byteSwapped)

}

}


extension EndianInteger {



@_transparent

public func _word(at n: Int) -> UInt {

return representingValue._word(at: n)

}



@_transparent

public func distance(to other: Self) -> RepresentingValue.Stride {

return self.representingValue.distance(to: other.representingValue)

}



@_transparent

public func advanced(by n: RepresentingValue.Stride) -> Self {

return Self(representingValue: self.representingValue.advanced(by:
n))

}



@_transparent

public func addingReportingOverflow(_ rhs: 

Re: [swift-evolution] [Pitch] Guard/Catch

[Elviro Rocca via swift-evolution]

Amazing proposal, I love it and thinking back there's plenty of times where I 
would have used the guard-catch instead of the non-swifty (to me) do-catch. A 
guard-catch construct still allows to handle errors explicitly, with the added 
convenience of forcing a return inside the catch, which is basically 100% of 
the cases for me. It's consistent with the semantics of "guard", that is, 
instead of indenting, exit the scope in the "negative" case.

I do not agree in mixing guard-catch with optional binding (+ bool conditions). 
I think it's clearer to keep the two separated, since you can always:

guard let x = try throwingFunction() catch { ... }
guard let y = x.optionalProperty, y == 42 else { ... }


Thanks


Elviro

> Il giorno 05 lug 2017, alle ore 19:40, Soroush Khanlou via swift-evolution 
> > ha scritto:
> 
> I’d like to propose a guard/catch construct to the language. It would allow 
> code to use throwing functions and handle errors fully, without straying from 
> a happy path. do/catch can be a bit heavy-handed sometimes, and it would be 
> nice to be able to handle throwing functions without committing to all the 
> nesting and ceremony of do/catch.
> 
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
> 
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> 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