Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Ankit Agarwal via swift-evolution]

> Swift, with its extension concept, is very well suited to modular
> development like this. We'd like to have a better option than frameworks to
> build reusable libraries. It's not an ABI thing, we really don't care about
> that, we use libs just to organize code, building them as a part of the
> app, and *not* to provide precompiled libraries to some other developers.
> Swift package manager does not work well within Xcode either at this time,
> and has a number of constraints we don't want (like having a separate git
> repo for each static lib -> that's not practical at all if you just have 1
> or 2 files in that lib).
>

You don't need to create one repo for each static library. A SwiftPM
package consists of Modules. You can create any number of products
consisting of one or more modules using the Product API in manifest file.
for eg:

products += [Product(name: "StaticLibA", type: .Library(.Static), modules:
"Foo"), Product(name: "StaticLibB", type: .Library(.Static), modules:
"Foo", "Bar")]

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

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

With NSError, you *must* check the domain before trying to interpret the
code, or else your code is buggy and will behave incorrectly when
receiving an unexpected error. With SE-0112, instead of checking the
domain, you check if the Error can be casted to the particular error
type that represents the domain. There is a one-to-one correspondence
between domains and the new error types. For example, NSCocoaErrorDomain
is represented by CocoaError, NSURLErrorDomain is URLError, etc.

So previously you might have code that looks like

func handleError(error: NSError) {
switch error.domain {
case NSCocoaErrorDomain where error.code == NSFileNoSuchFileError:
let path = error.userInfo[NSFilePathErrorKey] as? String
// handle error for path
case NSURLErrorDomain where error.code == NSURLErrorTimedOut:
let url = error.userInfo[NSURLErrorKey] as? NSURL
// handle error for url
default:
// generic handling of other errors
}
}

And now you'd write that like

func handleError(error: Error) {
switch error {
case let error as CocoaError where error.code ==
.fileNoSuchFileError:
let path = error.filePath
// handle error for path
case let error as URLError where error.code == .timedOut:
let url = error.failingURL
// handle error for url
default:
// generic handling of other errors
}
}

It's the same basic structure, except now you get strong typing, you
can't possibly forget to check the domain (which is a surprisingly
common bug I see in a lot of code), and you get convenient accessors for
the values stored in the user info.

And if you don't actually care about any of the user info properties,
then the new version is much simpler than the old:

func handleError(error: Error) {
switch error {
case CocoaError.fileNoSuchFileError:
// handle error
case URLError.timedOut:
// handle error
default:
// generic handling of other errors
}
}

It's similar to checking the code without the domain in the old style,
except now it checks the domain automatically, so you *still* can't
accidentally interpret an error's code in the wrong domain.

-Kevin Ballard

On Thu, Aug 4, 2016, at 11:00 AM, Jon Shier via swift-evolution wrote:
> Doug:
> Thanks for indulging me so far, I think I’ve almost got it. Prior to
> this, using NSError, I could just look at the relevant properties of
> the error if I needed to see what type it was. Network errors had
> different codes from CloudKit errors, POSIX errors were underlying
> FileManager errors. A bit complex due to the undocumented nature of so
> many of these errors, but I could ignore any aspect of the error I
> didn’t care about. Now, however, it seems I must always care about
> what types of errors come out of various methods, as I’ll need to cast
> to the appropriate types to get useful information. For example, how
> would you handle the CloudKit errors I mentioned before? It seems to
> me like I would need to, at the point where I need to extract useful
> information, do a switch on various casts. First, try casting to
> CKError, then to CocoaError (?), and then likely produce a fatalError
> if there’s an unexpected type. Or is Error guaranteed to always cast
> to something useful? I’ve read the proposal a few times now and it
> looks like a lot of casting is going to be required, I’m mostly
> curious about the recommended patterns, especially for asynchronous
> calls that don’t go through throw/catch.
>
>
>
> Jon
>
>
>> On Aug 2, 2016, at 5:36 PM, Douglas Gregor  wrote:
>>
>>
>>> On Aug 2, 2016, at 2:19 PM, Jon Shier  wrote:
>>>
>>> Thanks Doug. I missed the rename, as earlier points still referred
>>> to ErrorProtocol. In regards to the CloudKit errors, I appreciate
>>> the strongly typed CKError, but why not have the methods return that
>>> type directly?
>>
>> Generally speaking, Cocoa only uses NSError—not specific subclasses
>> or NSError or other error types—because errors can occur at many
>> different places in the stack and be propagated up. A CloudKit
>> operation could fail because of some problem detected in a different
>> error domain—say, the general Cocoa error domain or URLError
>> domain—and that non-CloudKit error would get passed through
>> immediately. So, if you were assuming that every error you get here
>> had to be in the CloudKit error domain, I believe your code was
>> already incorrect. It is *possible* that CloudKit translates/wraps
>> all other errors, but that would be odd for a Cocoa framework.
>>
>>> Every usage of these methods is going to require such a cast, so why
>>> require it in the first place? I don’t understand what advantage
>>> erasing the strongly type error that was just created has when the
>>> developer will just have to bring it right back. Or is this just a
>>> first implementation?
>>
>> There was never a strongly-typed error, and in most 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

Apple's developer forums need to rewrite in Swift.

On Fri, Aug 5, 2016 at 2:42 AM, Shawn Erickson via swift-evolution <
swift-evolution@swift.org> wrote:

> I concur on the general weakness of Apple's developer forums as they
> currently exist.
>
> On Thu, Aug 4, 2016 at 11:23 AM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Just wanted to point out that Apple’s forum software is pretty terrible,
>> even after two (apparent) rewrites. It’s buggy, navigates differently from
>> other forum software, doesn’t render code inline very well, and it doesn’t
>> offer the integrations that Discourse does.
>>
>>
>>
>> Jon
>>
>> On Aug 3, 2016, at 7:52 PM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 3, 2016, at 4:11 PM, David Owens II via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> But does it already surpass the limits?
>>
>> • There is a bandwidth limit of 100k monthly page views, equivalent to
>> our Standard hosting plan.
>> • If you exceed our bandwidth limit – which is very unlikely, unless your
>> project is enormous – you have two options:
>> • We’ll help you move to self-hosting, either on your own server or any
>> Docker compatible cloud (a $20/month Digital Ocean droplet should suffice).
>> • Upgrade to our Business hosting plan at 50% off.
>>
>>
>> I wouldn’t be surprised if it’s close if not passed 100k monthly views
>> already.
>>
>> The big unknown is also around the mailing list support. Is it super
>> robust and work as well for communicating as the mailing currently does? I
>> don’t know. I’ve not been involved with large projects on discourse.
>>
>>
>> Apple has a lot of money; I doubt being unable to go with the free option
>> would be a big dealbreaker.
>>
>> It should probably be mentioned, though, that Apple already has a
>> developer forum set up, and a server to run it on, and everything. Is there
>> any reason they couldn’t just use that?
>>
>> Charles
>>
>> ___
>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Manav Gabhawala  wrote:

>> > I investigated tuples a bit, it's close. The one thing I'd need is
>> > being able to index the values using a variable. The tuple.i
>> > notation apparently doesn't work (or I did not try hard
>> > enough). Also, for low-level things that will be mapped to GPU
>> > memory, precise/predictable/settable alignment is needed. 
>
> This might be a bit hacky but I just wanted to point out there exists
> a way to index into tuples.  You can use the Mirror(reflecting:
> tuple).children syntax. You can loop over the values of the tuple and
> even though a bit awkward you can even use indices to index into the
> children.

True, but the inefficiency of that approach pretty much defeats the
purpose of having a fixed-sized array.

>
> Regards,
> Manav Gabhawala
>
> On August 4, 2016 at 5:18:13 AM, James Froggatt via swift-evolution
> (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) wrote:
>
>>  
>>  
>> On 4 Aug 2016, at 13:00, Raphael Sebbe wrote:
>>  
>> > Thank you Chris, James.  
>> >  
>> > I'm answering James feedback/questions below.
>> >  
>> > On Thu, Aug 4, 2016 at 1:57 AM James Froggatt wrote:  
>> >  
>> > > What are your thoughts on using tuples for this?  
>> > >  
>> > > typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint)  
>> > >  
>> > > struct Quad { var corners: CGPoint4 }  
>> > >  
>> > > var fixedLength = (point1, point2, point3, point4)  
>> > > print(fixedLength.0)
>> > > print(fixedLength.4) //compiler error, not an element of the tuple
>> > >  
>> > >  
>> > > With shorthand declaration syntax, this would have the benefits
>> > > of a fixed-length array with added compile-time safety. A
>> > > previously suggested syntax was along the lines of '(CGPoint *
>> > > 4)'.
>> > >  
>> >  
>> > I investigated tuples a bit, it's close. The one thing I'd need is
>> > being able to index the values using a variable. The tuple.i
>> > notation apparently doesn't work (or I did not try hard
>> > enough). Also, for low-level things that will be mapped to GPU
>> > memory, precise/predictable/settable alignment is needed.
>>  
>> Good point. A similar mechanism might be possible eventually for
>> tuples, but right now this isn't possible.
>> > > > 4. Reference/pointer to structs: accessing & modifying structs
>> > > > deep into the model currently requires fully qualified path to
>> > > > the struct instance. Fully qualifying an inner struct in your
>> > > > data model can be very tedious, depending on model complexity.
>> > > >  
>> > > > For instance, with scoped access solutions made with Swift 3,
>> > > > you need to cascade blocks if you need to access multiple
>> > > > inner structs, which doesn't scale well as it creates code
>> > > > pyramids:
>> > > >  
>> > > > scopedAccess() {  
>> > > > scopedAccess() {  
>> > > > // modify varA & varB  
>> > > > }  
>> > > > }
>> > > >  
>> > > > It's easily done in C/C++ using pointers/references. To make
>> > > > that better, we'd need some kind of language support IMO.
>> > > >  
>> > > >  
>> > >  
>> > >  
>> > > Could this be generalised, maybe with a reference-semantic ‘property 
>> > > accessor’?  
>> > >  
>> > > Example:  
>> > >  
>> > > let get: () -> Bool = #get(controller.view.isVisible)  
>> > > print(get())
>> > >  
>> > > let set: (Bool) -> () = #set(controller.view.isVisible)  
>> > > set(true)
>> > >  
>> > > let accessor: Lens = #lens(controller.view.isVisible)  
>> > > print(accessor.value)
>> > > accessor.value = true
>> > >  
>> > > This would have the added bonus of also tracking the
>> > > reassignment of reference-type properties - in this example, if
>> > > 'view' is reassigned, the referenced value is updated.
>> >  
>> > Sounds good, I'm not aware of this syntax. Will investigate, thanks.  
>>  
>> Sorry, I was suggesting a *possible* syntax. No such syntax
>> currently exists, though the functionality can be imitated with
>> closures:
>>  
>> let get: () -> Bool = {controller.view.isVisible}  
>> print(get())
>>  
>> let set: (Bool) -> () = {controller.view.isVisible = $0}  
>> set(true)
>>  
>> struct Lens {  
>> var get: () -> T
>> var set: (T) -> ()
>> var value: T { get { return get() } set { set(newValue) } }
>> }
>> let accessor: Lens = Lens(get: {controller.view.isVisible}, set:
>> {controller.view.visible = $0})
>> print(accessor.value)
>> accessor.value = true
>>  
>>  
>> It's a bit more verbose when creating the get-set accessor, and may
>> not perform optimally, but it's actually pretty functional.
>> >  
>> > >  
>> > > > 5. Memory / pointer access, including casting. It's too
>> > > > verbose currently IMO when compared to C. Should be better
>> > > > supported for a language that is also targeting low-level
>> > > > (network, disk storage). A syntax that is both fast (like C)
>> > > > and safe would be great.
>> > >  
>> > > Not familiar with low-level programming in Swift, but have you
>> > > considered creating 

Re: [swift-evolution] [Idea] return if / return unless

[Julian Dunskus via swift-evolution]

On 05 Aug 2016, at 01:24, Brent Royal-Gordon  wrote:
> 
>> On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution 
>>  wrote:
>> 
>> return nil unless let thing = things[index]
> 
> On the `unless` part, at least, see the "Rename guard to unless" section in 
> Commonly Rejected Changes: 
> 
> 

I read that, see paragraph three of the email you replied to (my second in this 
thread)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Dave Abrahams  wrote:

> on Thu Aug 04 2016, Dmitri Gribenko  wrote:
>
>> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
>>  wrote:
>>> Could I suggest an alternative? It's conservative in that it mimics the
>>> relationships we had before the proposal was implemented and also maintains
>>> the simplicity of the caseless enum:
>>>
>>> ```
>>> extension MemoryLayout {
>>>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>>   // etc.
>>> }
>>> ```
>>
>> I like this API.  I think given all the alternatives that we explored,
>> it is better than those.  I also think that it nicely avoids the
>> following issue with the proposed MemoryLayout.of(type(of:
>> someExpression)).size syntax.
>>
>> Imagine that you have a value whose static type differs from the
>> dynamic type.  For example, a protocol existential:
>>
>> protocol P {}
>> extension Int : P {}
>> var x: P = 10
>>
>> The question is, what does MemoryLayout.of(type(of: x)).size compute,
>> size of the existential box, or the size of an Int instance?  The
>> semantics of 'type(of:)' are "return the dynamic type", so the
>> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>> returns the size of the dynamic type instance, of Int.
>>
>> What actually happens is that 'type(of: x)' returns a dynamic value of
>> 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
>> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>> x)).size returns the size of the protocol box.
>>
>> I think due to this complex interaction, using type(of:) might lead to
>> confusing code, and thus I like Xiaodi's approach better.
>>
>> Dmitri
>
> Okay, I'm convinced; that's what we should do.

Xiaodi, not to put you on the spot or anything... but how would you like
to write a proposal and create a pull request for the changes to the
standard library? ;-)

-- 
-Dave

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

Re: [swift-evolution] [Idea] return if / return unless

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Kurt Werle  wrote:

> Why would you do this just for return statements?  Why not do postfix
> conditionals for all statements (like ruby)?
>
> I've always liked postfix conditionals, but not enough to suggest them.

-1 from me.  Postfix conditionals are easily mistaken for unconditional
statements when reading quickly.  IMO always having the condition first
improves clarity.  Furthermore, postfix conditionals don't solve any
real problem in Swift AFAICT.

-- 
-Dave

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

[swift-evolution] [Accepted] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Daniel Dunbar via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

The review of "SE-0135: Package Manager Support for Differentiating Packages by 
Swift version" ran from Active review July 29...August 03. The proposal has 
been *accepted*.

There was little feedback on the proposal, in particular relative to the 
complexity of the proposal and space of possible things we could do. We found 
this unfortunate, but are still accepting the proposal for the following 
reasons:
1. Since we cannot anticipate in advance how widely or for how long the Swift 
3.0 package manager will be used, we feel it is important to have some escape 
hatch for Swift/SwiftPM version specific dependency selection.
2. The proposal is purely additive and intended to only be a short term 
mechanism. If it turns out to never be needed, or not suffice for the purpose 
for which it was designed, then we can remove it in a future release with 
little overhead.

- Daniel Dunbar
Review Manager

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

Re: [swift-evolution] [Idea] return if / return unless

[Brent Royal-Gordon via swift-evolution]

> On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution 
>  wrote:
> 
> return nil unless let thing = things[index]

On the `unless` part, at least, see the "Rename guard to unless" section in 
Commonly Rejected Changes: 


-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Dmitri Gribenko  wrote:

> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
>  wrote:
>> Could I suggest an alternative? It's conservative in that it mimics the
>> relationships we had before the proposal was implemented and also maintains
>> the simplicity of the caseless enum:
>>
>> ```
>> extension MemoryLayout {
>>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>   // etc.
>> }
>> ```
>
> I like this API.  I think given all the alternatives that we explored,
> it is better than those.  I also think that it nicely avoids the
> following issue with the proposed MemoryLayout.of(type(of:
> someExpression)).size syntax.
>
> Imagine that you have a value whose static type differs from the
> dynamic type.  For example, a protocol existential:
>
> protocol P {}
> extension Int : P {}
> var x: P = 10
>
> The question is, what does MemoryLayout.of(type(of: x)).size compute,
> size of the existential box, or the size of an Int instance?  The
> semantics of 'type(of:)' are "return the dynamic type", so the
> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> returns the size of the dynamic type instance, of Int.
>
> What actually happens is that 'type(of: x)' returns a dynamic value of
> 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> x)).size returns the size of the protocol box.
>
> I think due to this complex interaction, using type(of:) might lead to
> confusing code, and thus I like Xiaodi's approach better.
>
> Dmitri

Okay, I'm convinced; that's what we should do.

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

Re: [swift-evolution] MemoryLayout for a value

[Dmitri Gribenko via swift-evolution]

On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
 wrote:
> Could I suggest an alternative? It's conservative in that it mimics the
> relationships we had before the proposal was implemented and also maintains
> the simplicity of the caseless enum:
>
> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```

I like this API.  I think given all the alternatives that we explored,
it is better than those.  I also think that it nicely avoids the
following issue with the proposed MemoryLayout.of(type(of:
someExpression)).size syntax.

Imagine that you have a value whose static type differs from the
dynamic type.  For example, a protocol existential:

protocol P {}
extension Int : P {}
var x: P = 10

The question is, what does MemoryLayout.of(type(of: x)).size compute,
size of the existential box, or the size of an Int instance?  The
semantics of 'type(of:)' are "return the dynamic type", so the
straightforward conclusion is that MemoryLayout.of(type(of: x)).size
returns the size of the dynamic type instance, of Int.

What actually happens is that 'type(of: x)' returns a dynamic value of
'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
x)).size returns the size of the protocol box.

I think due to this complex interaction, using type(of:) might lead to
confusing code, and thus I like Xiaodi's approach better.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Daniel Dunbar via swift-evolution]

> On Aug 4, 2016, at 9:16 AM, Rob Allen  wrote:
> 
> I appreciate that I'm late on this, but I'm on vacation. 

Thanks for the response, I'm glad to be getting some additional feedback.

>> On 29 Jul 2016, at 20:36, Daniel Dunbar via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0135: Package Manager Support for Differentiating Packages 
>> by Swift version" begins now and runs through August 3rd. The proposal is 
>> available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-build-dev and swift-evolution mailing lists at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-build-dev
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to 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?
> 
> The solution is quite clear. I particularly like the concept of version 
> specific git tags. I'm less keen on version specific Package.swift files as I 
> feel that tags are meta data, but Package.swift isn't.
> 
> Personally, I'd prefer to only have version specific git tags, but 
> acknowledge that version-specific Package.swift files simplify the work for 
> some package maintainers. If you need different source code in Package.swift 
> and #if doesn't work, then I feel that you should use version specific git 
> tags as you would do for the rest of your code.

One primary motivation here was we wanted to encourage the use of packages 
which work across all modern Swift versions. That doesn't work out too well 
once you move to version specific tags if you are actively maintaining the 
compatibility as you would need to constantly retag and update Package.swift 
across the "branches" for each new version. We do agree it is unfortunate... 
the hope is this problem will go away quickly once the manifest API stabilizes.

 - Daniel

> 
> I'm pleased that this proposal is backwards compatible as both options can be 
> completely ignored for packages that don't need it. 
> 
> On the whole, +1.
> 
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Most definitely.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> It certainly acknowledges the current state of Swift language differences :)
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> This is quite elegant and more flexible than what I've seen elsewhere.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I read the proposal in detail.
> 
> Regards,
> 
> Rob..
> 

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Anders Bertelrud via swift-evolution]

On 2016-08-04, at 08.57, Daniel Dunbar via swift-build-dev 
 wrote:

> 2. This doesn't handle situations where we change the APIs within the 
> manifest itself -- older SwiftPM versions won't be able to parse them and 
> won't know what to do.

Also:  In discussing this, we also considered doing something like putting the 
version number in a comment line at the very top of the `Package.swift`, so 
that it could always be string-searched even in cases in which a new-format 
manifest isn't parseable by an older SwiftPM.

But that feels quite hacky, and we didn't want to do that if we could avoid it. 
 For one thing, we want to make newly created packages that support just the 
latest Swift not start out with a bunch of cruft in the form of specially 
formatted comments etc.  And secondly, well, it's just ugly.

Anders

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

Re: [swift-evolution] MemoryLayout for a value

[Anton Zhilin via swift-evolution]

2016-08-04 21:42 GMT+03:00 David Sweeris :
>
> Two quick questions:
> 1) Can the expensive bits of mirrors be done lazily?
> 2) IIRC, the reflection API is supposed to be reworked for Swift 4. With
> that in mind, are mirrors likely to remain too be expensive to construct
> for this approach?
>
> - Dave Sweeris


First is not really a problem, but we need reflection in place for my
suggestion. If we are going for a "quick fix", then we can't wait for full
API designed. I have to agree with Dave on that matter.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, David Sweeris  wrote:

>> On Aug 4, 2016, at 13:31, Dave Abrahams via swift-evolution
>>  wrote:
>> 
>> 
>>> on Thu Aug 04 2016, Anton Zhilin  wrote:
>
>>> 
>>> 2016-08-04 10:31 GMT+03:00 Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org>:
>>> 
> On Thu, Aug 4, 2016 at 2:29 AM, Karl  wrote:
> 
> It’s confusing because metatypes in Swift are pretty confusing in
> general: Int.self returns Int.Type which is not the same as `type(of: 
>  Int>)` (that would be Int).
> 
> If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
> Int.self) would return a MemoryLayout.
 
 Yes, here, I agree Dave is absolutely right. You and Dave have convinced
 me that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is
 an instance, would be appropriate.
>>> 
>>> Two weeks ago Adrian and I suggested adding dynamic 'size', 'stride',
>>> 'alignment' to Mirror, which definition would look like:
>>> 
>>> public struct Mirror {
>>>internal metatype_: Any.Type
>>> 
>>>public init(_: T.Type)
>>> 
>>>public var size: Int { get }
>>>public var stride: Int { get }
>>>public var align: Int { get }
>>> 
>>>// ...
>>> }
>>> 
>>> There are some problems with it right now, but I do believe that reflection
>>> API is where dynamic `size`, `stride`, `alignment` belong.
>> 
>> I see your point, but that would unfortunately be an unacceptably
>> expensive way to get that information.  Constructing a mirror is a
>> nontrivial bit of work.
>
> Two quick questions:
> 1) Can the expensive bits of mirrors be done lazily?
> 2) IIRC, the reflection API is supposed to be reworked for Swift
> 4. With that in mind, are mirrors likely to remain too be expensive to
> construct for this approach?

I don't know.  IMO none of these questions can be answered in time to
solve the cited problem for Swift 3.

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Shawn Erickson via swift-evolution]

I concur on the general weakness of Apple's developer forums as they
currently exist.

On Thu, Aug 4, 2016 at 11:23 AM Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> Just wanted to point out that Apple’s forum software is pretty terrible,
> even after two (apparent) rewrites. It’s buggy, navigates differently from
> other forum software, doesn’t render code inline very well, and it doesn’t
> offer the integrations that Discourse does.
>
>
>
> Jon
>
> On Aug 3, 2016, at 7:52 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Aug 3, 2016, at 4:11 PM, David Owens II via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> But does it already surpass the limits?
>
> • There is a bandwidth limit of 100k monthly page views, equivalent to
> our Standard hosting plan.
> • If you exceed our bandwidth limit – which is very unlikely, unless your
> project is enormous – you have two options:
> • We’ll help you move to self-hosting, either on your own server or any
> Docker compatible cloud (a $20/month Digital Ocean droplet should suffice).
> • Upgrade to our Business hosting plan at 50% off.
>
>
> I wouldn’t be surprised if it’s close if not passed 100k monthly views
> already.
>
> The big unknown is also around the mailing list support. Is it super
> robust and work as well for communicating as the mailing currently does? I
> don’t know. I’ve not been involved with large projects on discourse.
>
>
> Apple has a lot of money; I doubt being unable to go with the free option
> would be a big dealbreaker.
>
> It should probably be mentioned, though, that Apple already has a
> developer forum set up, and a server to run it on, and everything. Is there
> any reason they couldn’t just use that?
>
> Charles
>
> ___
> 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] MemoryLayout for a value

[David Sweeris via swift-evolution]

> On Aug 4, 2016, at 13:31, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Thu Aug 04 2016, Anton Zhilin  wrote:
>> 
>> 2016-08-04 10:31 GMT+03:00 Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>> 
 On Thu, Aug 4, 2016 at 2:29 AM, Karl  wrote:
 
 It’s confusing because metatypes in Swift are pretty confusing in
 general: Int.self returns Int.Type which is not the same as `type(of: >>> Int>)` (that would be Int).
 
 If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
 Int.self) would return a MemoryLayout.
>>> 
>>> Yes, here, I agree Dave is absolutely right. You and Dave have convinced
>>> me that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is
>>> an instance, would be appropriate.
>> 
>> Two weeks ago Adrian and I suggested adding dynamic 'size', 'stride',
>> 'alignment' to Mirror, which definition would look like:
>> 
>> public struct Mirror {
>>internal metatype_: Any.Type
>> 
>>public init(_: T.Type)
>> 
>>public var size: Int { get }
>>public var stride: Int { get }
>>public var align: Int { get }
>> 
>>// ...
>> }
>> 
>> There are some problems with it right now, but I do believe that reflection
>> API is where dynamic `size`, `stride`, `alignment` belong.
> 
> I see your point, but that would unfortunately be an unacceptably
> expensive way to get that information.  Constructing a mirror is a
> nontrivial bit of work.

Two quick questions:
1) Can the expensive bits of mirrors be done lazily?
2) IIRC, the reflection API is supposed to be reworked for Swift 4. With that 
in mind, are mirrors likely to remain too be expensive to construct for this 
approach?

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

Re: [swift-evolution] MemoryLayout for a value

[Anton Zhilin via swift-evolution]

2016-08-04 21:31 GMT+03:00 Dave Abrahams :

>
> on Thu Aug 04 2016, Anton Zhilin  wrote:
> > Two weeks ago Adrian and I suggested adding dynamic 'size', 'stride',
> > 'alignment' to Mirror, which definition would look like:
> >
> > public struct ReflectionWrapper {  // fixed!
> > internal metatype_: Any.Type
> >
> > public init(_: T.Type)
> >
> > public var size: Int { get }
> > public var stride: Int { get }
> > public var align: Int { get }
> >
> > // ...
> > }
> >
> > There are some problems with it right now, but I do believe that
> reflection
> > API is where dynamic `size`, `stride`, `alignment` belong.
>
> I see your point, but that would unfortunately be an unacceptably
> expensive way to get that information.  Constructing a mirror is a
> nontrivial bit of work.


I don't mean current heavyweight Mirror. Call that type ReflectionWrapper,
if you want. It would only contain 'Any.Type' stored property.
Largest of 'problems' that I meant is that reflection is postponed, and my
type would look odd without full reflection capabilities (only with 'size'
and friends).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Anton Zhilin  wrote:

> 2016-08-04 10:31 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
>> On Thu, Aug 4, 2016 at 2:29 AM, Karl  wrote:
>>
>>> It’s confusing because metatypes in Swift are pretty confusing in
>>> general: Int.self returns Int.Type which is not the same as `type(of: >> Int>)` (that would be Int).
>>>
>>> If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
>>> Int.self) would return a MemoryLayout.
>>>
>>
>> Yes, here, I agree Dave is absolutely right. You and Dave have convinced
>> me that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is
>> an instance, would be appropriate.
>>
>
> Two weeks ago Adrian and I suggested adding dynamic 'size', 'stride',
> 'alignment' to Mirror, which definition would look like:
>
> public struct Mirror {
> internal metatype_: Any.Type
>
> public init(_: T.Type)
>
> public var size: Int { get }
> public var stride: Int { get }
> public var align: Int { get }
>
> // ...
> }
>
> There are some problems with it right now, but I do believe that reflection
> API is where dynamic `size`, `stride`, `alignment` belong.

I see your point, but that would unfortunately be an unacceptably
expensive way to get that information.  Constructing a mirror is a
nontrivial bit of work.

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

Re: [swift-evolution] Improved value and move semantics

[Johannes Neubauer via swift-evolution]

> Am 04.08.2016 um 20:21 schrieb Joe Groff :
> 
>> 
>> On Aug 4, 2016, at 11:20 AM, Johannes Neubauer  wrote:
>> 
>> 
>>> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution 
>>> :
>>> 
 
 On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
 
> 
> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
> 
> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
> 
> a. We indirect automatically based on some heuristic, as an
> optimization.
>>> 
>>> I weakly disagree with this, because it is important that we provide a 
>>> predictable model.  I’d rather the user get what they write, and tell 
>>> people to write ‘indirect’ as a performance tuning option.  “Too magic” 
>>> is bad.
>> 
>> I think 'indirect' structs with a heuristic default are important to the 
>> way people are writing Swift in practice. We've seen many users fully 
>> invest in value semantics types, because they wants the benefits of 
>> isolated state, without appreciating the code size and performance 
>> impacts. Furthermore, implementing 'indirect' by hand is a lot of 
>> boilerplate. Putting indirectness entirely in users' hands feels to me a 
>> lot like the "value if word sized, const& if struct" heuristics C++ 
>> makes you internalize, since there are similar heuristics where 
>> 'indirect' is almost always a win in Swift too.
> 
> I understand with much of your motivation, but I still disagree with your 
> conclusion.  I see this as exactly analogous to the situation and 
> discussion when we added indirect to enums.  At the time, some argued for 
> a magic model where the compiler figured out what to do in the most 
> common “obvious” cases.
> 
> We agreed to use our current model though because:
> 1) Better to be explicit about allocations & indirection that implicit.
> 2) The compiler can guide the user in the “obvious” case to add the 
> keyword with a fixit, preserving the discoverability / ease of use.
> 3) When indirection is necessary, there are choices to make about where 
> the best place to do it is.
> 4) In the most common case, the “boilerplate” is a single “indirect” 
> keyword added to the enum decl itself.  In the less common case, you want 
> the “boilerplate” so that you know where the indirections are happening.
> 
> Overall, I think this model has worked well for enums and I’m still very 
> happy with it.  If you generalize it to structs, you also have to 
> consider that this should be part of a larger model that includes better 
> support for COW.  I think it would be really unfortunate to “magically 
> indirect” struct, when the right answer may actually be to COW them 
> instead.  I’d rather have a model where someone can use:
> 
> // simple, predictable, always inline, slow in some cases.
> struct S1 { … }
> 
> And then upgrade to one of:
> 
> indirect struct S2 {…}
> cow struct S3 { … }
> 
> Depending on the structure of their data.  In any case, to reiterate, 
> this really isn’t the time to have this debate, since it is clearly 
> outside of stage 1.
 
 In my mind, indirect *is* cow. An indirect struct without value semantics 
 is a class, so there would be no reason to implement 'indirect' for 
 structs without providing copy-on-write behavior.
>>> 
>>> This is my view as well.  Chris, what is the distinction in your mind?
>>> 
 I believe that the situation with structs and enums is also different. 
 Indirecting enums has a bigger impact on interface because they enable 
 recursive data structures, and while there are places where indirecting a 
 struct may make new recursion possible, that's much rarer of a reason to 
 introduce indirectness for structs. Performance and code size are the more 
 common reasons, and we've described how to build COW boxes manually to 
 work around performance problems at the last two years' WWDC. There are 
 pretty good heuristics for when indirection almost always beats inline 
 storage: once you have more than one refcounted field, passing around a 
 box and retaining once becomes cheaper than retaining the fields 
 individually. Once you exceed the fixed-sized buffer threshold of three 
 words, indirecting some or all of your fields becomes necessary to avoid 
 falling off a cliff in unspecialized generic or protocol-type-based code.  
 Considering that we hope to explore other layout optimizations, such as 
 automatically reordering fields to minimize padding, and that, as with 
 padding, there are simple rules for indirecting that can be mechanically 
 followed to get good results in the 99% case, it seems perfectly 

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Thu Aug 04 2016, Xiaodi Wu  wrote:

> On Wed, Aug 3, 2016 at 11:32 PM, Dave Abrahams  wrote:
>
>>
>> on Wed Aug 03 2016, Xiaodi Wu  wrote:
>>
>> > Agreed, but I do think "memory layout of type of my value, size" is a
>> > mouthful compared to "size of value".
>>
>> It is, but it would avoid confusion.
>>
>> > Moreover, something doesn't sit right with me that MemoryLayout and
>> > MemoryLayout.of(T.self) would be one and the same thing.
>>
>> As far as I'm concerned, that's a feature, not a bug.  Unless you can
>> describe why it should be different, “it doesn't sit right” is not a
>> helpful argument.
>>
>
> Originally, I'd actually half-way typed out a fuller argument, then deleted
> it, assuming most would find it to be uninteresting due to obviousness.
> Let's see:
>
> Unless I'm mistaken, every place where one might write `MemoryLayout`
> can be replaced with `MemoryLayout.of(T.self)`. 

In my proposal, yes.

> (Yes, I understand that there are places where substituting in the
> other direction would be unsatisfactory, hence this follow-up thread.)
> However, I understand it to be a bug, not a feature, to have two
> different ways of spelling the same thing, because it necessarily
> brings confusion as to why there must be two of them, and I therefore
> consider this proposed design to be suboptimal.  You titled this
> thread "MemoryLayout for a value": I agree that that's what we
> need. It ought to be possible to provide facilities for exactly that
> *without* also providing an entirely duplicative way of spelling
> MemoryLayout for a type.

Fair enough.

>> > Could I suggest an alternative? It's conservative in that it mimics
>> > the relationships we had before the proposal was implemented and
>> > also maintains the simplicity of the caseless enum:
>> >
>> > ```
>> > extension MemoryLayout {
>> >   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>> >   // etc.
>> > }
>> > ```
>>
>> That introduces even more potential for confusion than adding forwarding
>> vars to instances does.  Now you're talking about “overloading” a static
>> property with a static method having the same base name.
>
> IMO, here's where it's a feature, not a bug. I propose `size(ofValue:)` and
> `size` because they *are* related, just like how `first(where:)` and
> `first` are related for a Collection. 

GOod point.

> Moreover, the whole thing reads exactly as it should (and, not by
> accident, nearly identically to this thread's subject line): "memory
> layout size of value x". What is the source of confusion that you
> think would arise from this pseudo-overloading, and why are you
> emphasizing the fact that both would be static properties/methods (is
> it less confusing when it's not static)?

It's less confusing when only one of them is static and the other isn't.

But you've made some excellent points here.  Mulling...

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

Re: [swift-evolution] Improved value and move semantics

[Joe Groff via swift-evolution]

> On Aug 4, 2016, at 11:20 AM, Johannes Neubauer  wrote:
> 
> 
>> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution 
>> :
>> 
>>> 
>>> On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
>>> 
 
 On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
 
 On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
 
 a. We indirect automatically based on some heuristic, as an
 optimization.
>> 
>> I weakly disagree with this, because it is important that we provide a 
>> predictable model.  I’d rather the user get what they write, and tell 
>> people to write ‘indirect’ as a performance tuning option.  “Too magic” 
>> is bad.
> 
> I think 'indirect' structs with a heuristic default are important to the 
> way people are writing Swift in practice. We've seen many users fully 
> invest in value semantics types, because they wants the benefits of 
> isolated state, without appreciating the code size and performance 
> impacts. Furthermore, implementing 'indirect' by hand is a lot of 
> boilerplate. Putting indirectness entirely in users' hands feels to me a 
> lot like the "value if word sized, const& if struct" heuristics C++ makes 
> you internalize, since there are similar heuristics where 'indirect' is 
> almost always a win in Swift too.
 
 I understand with much of your motivation, but I still disagree with your 
 conclusion.  I see this as exactly analogous to the situation and 
 discussion when we added indirect to enums.  At the time, some argued for 
 a magic model where the compiler figured out what to do in the most common 
 “obvious” cases.
 
 We agreed to use our current model though because:
 1) Better to be explicit about allocations & indirection that implicit.
 2) The compiler can guide the user in the “obvious” case to add the 
 keyword with a fixit, preserving the discoverability / ease of use.
 3) When indirection is necessary, there are choices to make about where 
 the best place to do it is.
 4) In the most common case, the “boilerplate” is a single “indirect” 
 keyword added to the enum decl itself.  In the less common case, you want 
 the “boilerplate” so that you know where the indirections are happening.
 
 Overall, I think this model has worked well for enums and I’m still very 
 happy with it.  If you generalize it to structs, you also have to consider 
 that this should be part of a larger model that includes better support 
 for COW.  I think it would be really unfortunate to “magically indirect” 
 struct, when the right answer may actually be to COW them instead.  I’d 
 rather have a model where someone can use:
 
 // simple, predictable, always inline, slow in some cases.
 struct S1 { … }
 
 And then upgrade to one of:
 
 indirect struct S2 {…}
 cow struct S3 { … }
 
 Depending on the structure of their data.  In any case, to reiterate, this 
 really isn’t the time to have this debate, since it is clearly outside of 
 stage 1.
>>> 
>>> In my mind, indirect *is* cow. An indirect struct without value semantics 
>>> is a class, so there would be no reason to implement 'indirect' for structs 
>>> without providing copy-on-write behavior.
>> 
>> This is my view as well.  Chris, what is the distinction in your mind?
>> 
>>> I believe that the situation with structs and enums is also different. 
>>> Indirecting enums has a bigger impact on interface because they enable 
>>> recursive data structures, and while there are places where indirecting a 
>>> struct may make new recursion possible, that's much rarer of a reason to 
>>> introduce indirectness for structs. Performance and code size are the more 
>>> common reasons, and we've described how to build COW boxes manually to work 
>>> around performance problems at the last two years' WWDC. There are pretty 
>>> good heuristics for when indirection almost always beats inline storage: 
>>> once you have more than one refcounted field, passing around a box and 
>>> retaining once becomes cheaper than retaining the fields individually. Once 
>>> you exceed the fixed-sized buffer threshold of three words, indirecting 
>>> some or all of your fields becomes necessary to avoid falling off a cliff 
>>> in unspecialized generic or protocol-type-based code.  Considering that we 
>>> hope to explore other layout optimizations, such as automatically 
>>> reordering fields to minimize padding, and that, as with padding, there are 
>>> simple rules for indirecting that can be mechanically followed to get good 
>>> results in the 99% case, it seems perfectly reasonable to me to automate 
>>> this.
>>> 
>>> -Joe
>> 
>> I think everyone is making good points in this discussion.  Predictability 
>> is an important 

Re: [swift-evolution] Improved value and move semantics

[Johannes Neubauer via swift-evolution]

> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution 
> :
> 
>> 
>> On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
>> 
>>> 
>>> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
>>> 
>>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>>> 
>>> a. We indirect automatically based on some heuristic, as an
>>> optimization.
> 
> I weakly disagree with this, because it is important that we provide a 
> predictable model.  I’d rather the user get what they write, and tell 
> people to write ‘indirect’ as a performance tuning option.  “Too magic” 
> is bad.
 
 I think 'indirect' structs with a heuristic default are important to the 
 way people are writing Swift in practice. We've seen many users fully 
 invest in value semantics types, because they wants the benefits of 
 isolated state, without appreciating the code size and performance 
 impacts. Furthermore, implementing 'indirect' by hand is a lot of 
 boilerplate. Putting indirectness entirely in users' hands feels to me a 
 lot like the "value if word sized, const& if struct" heuristics C++ makes 
 you internalize, since there are similar heuristics where 'indirect' is 
 almost always a win in Swift too.
>>> 
>>> I understand with much of your motivation, but I still disagree with your 
>>> conclusion.  I see this as exactly analogous to the situation and 
>>> discussion when we added indirect to enums.  At the time, some argued for a 
>>> magic model where the compiler figured out what to do in the most common 
>>> “obvious” cases.
>>> 
>>> We agreed to use our current model though because:
>>> 1) Better to be explicit about allocations & indirection that implicit.
>>> 2) The compiler can guide the user in the “obvious” case to add the keyword 
>>> with a fixit, preserving the discoverability / ease of use.
>>> 3) When indirection is necessary, there are choices to make about where the 
>>> best place to do it is.
>>> 4) In the most common case, the “boilerplate” is a single “indirect” 
>>> keyword added to the enum decl itself.  In the less common case, you want 
>>> the “boilerplate” so that you know where the indirections are happening.
>>> 
>>> Overall, I think this model has worked well for enums and I’m still very 
>>> happy with it.  If you generalize it to structs, you also have to consider 
>>> that this should be part of a larger model that includes better support for 
>>> COW.  I think it would be really unfortunate to “magically indirect” 
>>> struct, when the right answer may actually be to COW them instead.  I’d 
>>> rather have a model where someone can use:
>>> 
>>> // simple, predictable, always inline, slow in some cases.
>>> struct S1 { … }
>>> 
>>> And then upgrade to one of:
>>> 
>>> indirect struct S2 {…}
>>> cow struct S3 { … }
>>> 
>>> Depending on the structure of their data.  In any case, to reiterate, this 
>>> really isn’t the time to have this debate, since it is clearly outside of 
>>> stage 1.
>> 
>> In my mind, indirect *is* cow. An indirect struct without value semantics is 
>> a class, so there would be no reason to implement 'indirect' for structs 
>> without providing copy-on-write behavior.
> 
> This is my view as well.  Chris, what is the distinction in your mind?
> 
>> I believe that the situation with structs and enums is also different. 
>> Indirecting enums has a bigger impact on interface because they enable 
>> recursive data structures, and while there are places where indirecting a 
>> struct may make new recursion possible, that's much rarer of a reason to 
>> introduce indirectness for structs. Performance and code size are the more 
>> common reasons, and we've described how to build COW boxes manually to work 
>> around performance problems at the last two years' WWDC. There are pretty 
>> good heuristics for when indirection almost always beats inline storage: 
>> once you have more than one refcounted field, passing around a box and 
>> retaining once becomes cheaper than retaining the fields individually. Once 
>> you exceed the fixed-sized buffer threshold of three words, indirecting some 
>> or all of your fields becomes necessary to avoid falling off a cliff in 
>> unspecialized generic or protocol-type-based code.  Considering that we hope 
>> to explore other layout optimizations, such as automatically reordering 
>> fields to minimize padding, and that, as with padding, there are simple 
>> rules for indirecting that can be mechanically followed to get good results 
>> in the 99% case, it seems perfectly reasonable to me to automate this.
>> 
>> -Joe
> 
> I think everyone is making good points in this discussion.  Predictability is 
> an important value, but so is default performance.  To some degree there is a 
> natural tension between them, but I think it can be mitigated.
> 
> Swift relies so heavily on the optimizer for 

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jon Shier via swift-evolution]

Doug:
Thanks for indulging me so far, I think I’ve almost got it. Prior to 
this, using NSError, I could just look at the relevant properties of the error 
if I needed to see what type it was. Network errors had different codes from 
CloudKit errors, POSIX errors were underlying FileManager errors. A bit complex 
due to the undocumented nature of so many of these errors, but I could ignore 
any aspect of the error I didn’t care about. Now, however, it seems I must 
always care about what types of errors come out of various methods, as I’ll 
need to cast to the appropriate types to get useful information. For example, 
how would you handle the CloudKit errors I mentioned before? It seems to me 
like I would need to, at the point where I need to extract useful information, 
do a switch on various casts. First, try casting to CKError, then to CocoaError 
(?), and then likely produce a fatalError if there’s an unexpected type. Or is 
Error guaranteed to always cast to something useful? I’ve read the proposal a 
few times now and it looks like a lot of casting is going to be required, I’m 
mostly curious about the recommended patterns, especially for asynchronous 
calls that don’t go through throw/catch. 



Jon


> On Aug 2, 2016, at 5:36 PM, Douglas Gregor  wrote:
> 
> 
>> On Aug 2, 2016, at 2:19 PM, Jon Shier > > wrote:
>> 
>>  Thanks Doug. I missed the rename, as earlier points still referred to 
>> ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly 
>> typed CKError, but why not have the methods return that type directly?
> 
> Generally speaking, Cocoa only uses NSError—not specific subclasses or 
> NSError or other error types—because errors can occur at many different 
> places in the stack and be propagated up. A CloudKit operation could fail 
> because of some problem detected in a different error domain—say, the general 
> Cocoa error domain or URLError domain—and that non-CloudKit error would get 
> passed through immediately. So, if you were assuming that every error you get 
> here had to be in the CloudKit error domain, I believe your code was already 
> incorrect. It is *possible* that CloudKit translates/wraps all other errors, 
> but that would be odd for a Cocoa framework.
> 
>> Every usage of these methods is going to require such a cast, so why require 
>> it in the first place? I don’t understand what advantage erasing the 
>> strongly type error that was just created has when the developer will just 
>> have to bring it right back. Or is this just a first implementation?
> 
> There was never a strongly-typed error, and in most Cocoa cases there 
> shouldn’t be one because NSError covers all error domains, by design.
> 
>   - Doug
> 
> 
>> 
>> 
>> Jon
>> 
>>> On Aug 2, 2016, at 4:20 PM, Douglas Gregor >> > wrote:
>>> 
 
 On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution 
 > wrote:
 
I’m not sure where to put such feedback, but the ErrorProtocol to Error 
 rename that accompanied the implementation of this proposal is very, very 
 painful. It completely eliminates the very useful ability to embed an 
 associated Error type inside other types, as those types now conflict with 
 the protocol. Also, was this rename accompanied by an evolution proposal? 
 It seems like the change was just made when this proposal was implemented.
>>> 
>>> The rename was part of the proposal, in bullet #5 of the proposed solution 
>>> (which, amusing, pastes as bullet #1 below):
>>> 
>>> Rename ErrorProtocol to Error: once we've completed the bridging story, 
>>> Error becomes the primary way to work with error types in Swift, and the 
>>> value type to which NSError is bridged:
>>> 
>>> func handleError(_ error: Error, userInteractionPermitted: Bool)
>>> 
>>> 
Also, the adoption of this proposal by the Cocoa(Touch) frameworks as 
 seen in Xcode 8 beta 4 has made asynchronous error handling quite a bit 
 more arduous. For example, the CKDatabase method fetch(withRecordID 
 recordID: CKRecordID, completionHandler: (CKRecord?, Error?) -> Void) 
 returns an `Error` now, meaning I have to cast to the specific `CKError` 
 type to get useful information out of it. Is this just an unfortunate 
 first effort that will be fixed, or is this the expected form of these 
 sorts of APIs after this proposal?
>>> 
>>> Prior to this proposal, you would have had to check the domain against 
>>> CKErrorDomain anyway to determine whether you’re looking at a CloudKit 
>>> error (vs. some other error that is passing through CloudKit), so error 
>>> bridging shouldn’t actually be adding any work here—although it might be 
>>> making explicit work that was already done or should have been done. Once 
>>> you have casted to CKError, you 

Re: [swift-evolution] swift-evolution Digest, Vol 9, Issue 8

[Adrian Brink via swift-evolution]

On Thursday, 4 August 2016,  wrote:

> Send swift-evolution mailing list submissions to
> swift-evolution@swift.org 
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, via email, send a message with subject or body 'help' to
> swift-evolution-requ...@swift.org 
>
> You can reach the person managing the list at
> swift-evolution-ow...@swift.org 
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-evolution digest..."
>


-- 
Faithfully,
*Adrian Brink*
Brink Holdings

mobile: DK: +45 52 81 01 26; UK: +44 (0) 7949308282; GE: +49 (0) 15737308279
email: adr...@brink-holdings.com
website: adrianbrink.com
twitter: twitter.com 
facebook: facebook.com 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Daniel Dunbar via swift-evolution]

Hi Max,

> On Aug 4, 2016, at 6:46 AM, Max Desiatov  wrote:
> 
> Hi Daniel,
> 
> I hope this proposal really is still in active review, as it is marked as 
> such in the swift-evolution Git repository.

It was supposed to close yesterday, but I haven't gotten to the paperwork. We 
have received very little feedback on the proposal so I appreciate your reply.

> I did a quick reading of this proposal and I like it very much. I think that 
> it provides a solution that is additive and doesn't break any existing 
> package specifications.
> 
> With the amount of source-breaking changes in Swift, I think this proposal is 
> really important and I hope that it still will be implemented in Swift 3 
> timeframe. Especially as SwiftPM is not as tightly coupled with the core 
> compiler infrastructure, this would be a good timing to introduce this to 
> help people in transitioning from Swift 2.2 to Swift 3.
> 
> Have you previously considered also adding a field to manifests, that will 
> allow to declare the supported version in the dependency manifest itself? As 
> in:

We did consider this, but it has two major problems:

1. The list is cumbersome to maintain, particularly when the expectation is 
that new Swift versions do not break the package, and thus it remains 
compatible. A feature like this has the problem that once added, it requires 
maintenance in every package even once it has outlived its utility: As long as 
some package is used by SwiftPM-3.0 it has to keep the annotations, even if 
just to tell that version to look elsewhere.

2. This doesn't handle situations where we change the APIs within the manifest 
itself -- older SwiftPM versions won't be able to parse them and won't know 
what to do.

 - Daniel

> 
> let package =
> Package(
>name: "Foo",
>swiftVersions: ["3.0", "2.1"]
> )
> 
> This would make it impossible to even try to build this module with Swift 
> 2.1, thus saving time by not doing a build that will inevitably fail. This 
> would also help packages supporting both versions in the same source tree 
> with #ifdef swift version conditionals. I do realise that my suggestion will 
> not be considered for Swift 3, but I look forward to your feedback on this.
> 
> Thanks!
> 
> ---
> With best regards, Max.
> 
>> On 29 Jul 2016, at 21:36, Daniel Dunbar via swift-build-dev 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0135: Package Manager Support for Differentiating Packages 
>> by Swift version" begins now and runs through August 3rd. The proposal is 
>> available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-build-dev and swift-evolution mailing lists at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-build-dev
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to 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,
>> 
>> - Daniel Dunbar
>> Review Manager
>> 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 

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

Re: [swift-evolution] [Idea] return if / return unless

[Julian Dunskus via swift-evolution]

Having postfix conditionals for return would be a lot easier to implement than 
having them everywhere, because you just need to watch for an if or unless 
after the return. Of course they might come in handy elsewhere, and may even 
solve the ever-present problem of the unintuitive ternary operator ?:, but 
that’s a whole different discussion. This proposal is simply about having some 
syntactic sugar for return statements.

Seeing as this change would be purely additive and adding more keywords to 
Swift is not really a problem (we can use them as parameter labels etc.), I 
don’t really see a reason against it.

Using “unless” for this makes sense especially as a postfix. I agree with 
keeping guard around, but this statement is different from guard in that the 
code executed if the condition can’t be satisfied is stated before the keyword, 
which makes it read well.

In case of the guard statement, you’d need another keyword to make “unless” 
logical, like unless foo != nil inWhichCase {}, which just feels bulky to me.

Additionally, return nil guard let thing = things[index] does not read 
logically to me.

–Julian

> On 04 Aug 2016, at 17:03, David Rönnqvist via swift-evolution 
>  wrote:
> 
> One complication with allowing postfix conditionals for all statements is 
> that it often needs to have an else clause as well (like the ternary operator 
> “?:").
> 
> For example, what’s the type of “x” below?
> 
> let x = 5 if someCriteria()
> 
> And is “y” initialized or not?
> 
> let y: Int
> y = 42 if someCriteria()
> doSomething(with: y)
> 
> I realize that this idea is more about the feature/behavior than the naming, 
> but renaming “guard” to “unless” is one of the commonly rejected proposals.
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 
> 
> 
> - David
> 
> 
>> On 04 Aug 2016, at 16:52, Kurt Werle via swift-evolution 
>> > wrote:
>> 
>> Why would you do this just for return statements?  Why not do postfix 
>> conditionals for all statements (like ruby)?
>> 
>> I've always liked postfix conditionals, but not enough to suggest them.  
>> Mostly I'm curious about limiting the scope to return statements.
>> 
>> On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution 
>> > wrote:
>> +1
>> 
>> 2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution 
>> >:
>> How often have you written something like the following?
>> 
>> `
>> if indexPath.row == 0 { return }
>> 
>> guard let thing = things[index] else { return nil }
>> `
>> 
>> I propose adding some syntactic sugar to make such statements more readable 
>> and simple to write:
>> 
>> `
>> return if indexPath.row == 0
>> 
>> return nil unless let thing = things[index]
>> `
>> 
>> I don’t know how easy or hard this would be to implement, but I think it 
>> would improve some code significantly.
>> 
>> –Julian Dunskus
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Mit freundlichen Grüßen
>> 
>> Christian Kienle
>> Mobile Developer
>> 
>> REWE Digital GmbH
>> Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
>> Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender), 
>> Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
>> Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450
>> 
>> Telefon: +49 151 11441782
>> E-Mail: christian.kie...@rewe-digital.com 
>> 
>> Internet: www.rewe-digital.com 
>> 
>> Ein Unternehmen der REWE GROUP
>> http://www.rewe-group.com 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> k...@circlew.org 
>> http://www.CircleW.org/kurt/ 
>> ___
>> 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

Re: [swift-evolution] Improved value and move semantics

[Matthew Johnson via swift-evolution]

> On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
> 
>> 
>> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
>> 
>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>> 
>> a. We indirect automatically based on some heuristic, as an
>> optimization.
 
 I weakly disagree with this, because it is important that we provide a 
 predictable model.  I’d rather the user get what they write, and tell 
 people to write ‘indirect’ as a performance tuning option.  “Too magic” is 
 bad.
>>> 
>>> I think 'indirect' structs with a heuristic default are important to the 
>>> way people are writing Swift in practice. We've seen many users fully 
>>> invest in value semantics types, because they wants the benefits of 
>>> isolated state, without appreciating the code size and performance impacts. 
>>> Furthermore, implementing 'indirect' by hand is a lot of boilerplate. 
>>> Putting indirectness entirely in users' hands feels to me a lot like the 
>>> "value if word sized, const& if struct" heuristics C++ makes you 
>>> internalize, since there are similar heuristics where 'indirect' is almost 
>>> always a win in Swift too.
>> 
>> I understand with much of your motivation, but I still disagree with your 
>> conclusion.  I see this as exactly analogous to the situation and discussion 
>> when we added indirect to enums.  At the time, some argued for a magic model 
>> where the compiler figured out what to do in the most common “obvious” 
>> cases.  
>> 
>> We agreed to use our current model though because:
>> 1) Better to be explicit about allocations & indirection that implicit.  
>> 2) The compiler can guide the user in the “obvious” case to add the keyword 
>> with a fixit, preserving the discoverability / ease of use.
>> 3) When indirection is necessary, there are choices to make about where the 
>> best place to do it is.
>> 4) In the most common case, the “boilerplate” is a single “indirect” keyword 
>> added to the enum decl itself.  In the less common case, you want the 
>> “boilerplate” so that you know where the indirections are happening.
>> 
>> Overall, I think this model has worked well for enums and I’m still very 
>> happy with it.  If you generalize it to structs, you also have to consider 
>> that this should be part of a larger model that includes better support for 
>> COW.  I think it would be really unfortunate to “magically indirect” struct, 
>> when the right answer may actually be to COW them instead.  I’d rather have 
>> a model where someone can use:
>> 
>> // simple, predictable, always inline, slow in some cases.
>> struct S1 { … }  
>> 
>> And then upgrade to one of:
>> 
>> indirect struct S2 {…}
>> cow struct S3 { … } 
>> 
>> Depending on the structure of their data.  In any case, to reiterate, this 
>> really isn’t the time to have this debate, since it is clearly outside of 
>> stage 1.
> 
> In my mind, indirect *is* cow. An indirect struct without value semantics is 
> a class, so there would be no reason to implement 'indirect' for structs 
> without providing copy-on-write behavior.

This is my view as well.  Chris, what is the distinction in your mind?

> I believe that the situation with structs and enums is also different. 
> Indirecting enums has a bigger impact on interface because they enable 
> recursive data structures, and while there are places where indirecting a 
> struct may make new recursion possible, that's much rarer of a reason to 
> introduce indirectness for structs. Performance and code size are the more 
> common reasons, and we've described how to build COW boxes manually to work 
> around performance problems at the last two years' WWDC. There are pretty 
> good heuristics for when indirection almost always beats inline storage: once 
> you have more than one refcounted field, passing around a box and retaining 
> once becomes cheaper than retaining the fields individually. Once you exceed 
> the fixed-sized buffer threshold of three words, indirecting some or all of 
> your fields becomes necessary to avoid falling off a cliff in unspecialized 
> generic or protocol-type-based code.  Considering that we hope to explore 
> other layout optimizations, such as automatically reordering fields to 
> minimize padding, and that, as with padding, there are simple rules for 
> indirecting that can be mechanically followed to get good results in the 99% 
> case, it seems perfectly reasonable to me to automate this.
> 
> -Joe


I think everyone is making good points in this discussion.  Predictability is 
an important value, but so is default performance.  To some degree there is a 
natural tension between them, but I think it can be mitigated.  

Swift relies so heavily on the optimizer for performance that I don’t think the 
default performance is ever going to be perfectly predictable.  But that’s 
actually a good thing because, as this allows the compiler to provide *better* 
performance 

Re: [swift-evolution] [Idea] return if / return unless

[David Rönnqvist via swift-evolution]

One complication with allowing postfix conditionals for all statements is that 
it often needs to have an else clause as well (like the ternary operator “?:").

For example, what’s the type of “x” below?

let x = 5 if someCriteria()

And is “y” initialized or not?

let y: Int
y = 42 if someCriteria()
doSomething(with: y)

I realize that this idea is more about the feature/behavior than the naming, 
but renaming “guard” to “unless” is one of the commonly rejected proposals.
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

- David


> On 04 Aug 2016, at 16:52, Kurt Werle via swift-evolution 
>  wrote:
> 
> Why would you do this just for return statements?  Why not do postfix 
> conditionals for all statements (like ruby)?
> 
> I've always liked postfix conditionals, but not enough to suggest them.  
> Mostly I'm curious about limiting the scope to return statements.
> 
> On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution 
> > wrote:
> +1
> 
> 2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution 
> >:
> How often have you written something like the following?
> 
> `
> if indexPath.row == 0 { return }
> 
> guard let thing = things[index] else { return nil }
> `
> 
> I propose adding some syntactic sugar to make such statements more readable 
> and simple to write:
> 
> `
> return if indexPath.row == 0
> 
> return nil unless let thing = things[index]
> `
> 
> I don’t know how easy or hard this would be to implement, but I think it 
> would improve some code significantly.
> 
> –Julian Dunskus
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
> Mit freundlichen Grüßen
> 
> Christian Kienle
> Mobile Developer
> 
> REWE Digital GmbH
> Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
> Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender), Christoph 
> Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
> Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450
> 
> Telefon: +49 151 11441782
> E-Mail: christian.kie...@rewe-digital.com 
> 
> Internet: www.rewe-digital.com 
> 
> Ein Unternehmen der REWE GROUP
> http://www.rewe-group.com 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
> k...@circlew.org
> http://www.CircleW.org/kurt/ 
> ___
> 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] [Idea] return if / return unless

[Kurt Werle via swift-evolution]

Why would you do this just for return statements?  Why not do postfix
conditionals for all statements (like ruby)?

I've always liked postfix conditionals, but not enough to suggest them.
Mostly I'm curious about limiting the scope to return statements.

On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> 2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution <
> swift-evolution@swift.org>:
>
>> How often have you written something like the following?
>>
>> `
>> if indexPath.row == 0 { return }
>>
>> guard let thing = things[index] else { return nil }
>> `
>>
>> I propose adding some syntactic sugar to make such statements more
>> readable and simple to write:
>>
>> `
>> return if indexPath.row == 0
>>
>> return nil unless let thing = things[index]
>> `
>>
>> I don’t know how easy or hard this would be to implement, but I think it
>> would improve some code significantly.
>>
>> –Julian Dunskus
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Mit freundlichen Grüßen
>
> *Christian Kienle*
> Mobile Developer
>
> *REWE Digital GmbH*
> Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
> Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender),
> Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
> Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450
>
> Telefon: +49 151 11441782
> E-Mail: christian.kie...@rewe-digital.com
> Internet: *www.rewe-digital.com *
>
> Ein Unternehmen der *REWE GROUP*
> http://www.rewe-group.com
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Joe Groff via swift-evolution]

> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
> 
> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
> 
> a. We indirect automatically based on some heuristic, as an
> optimization.
>>> 
>>> I weakly disagree with this, because it is important that we provide a 
>>> predictable model.  I’d rather the user get what they write, and tell 
>>> people to write ‘indirect’ as a performance tuning option.  “Too magic” is 
>>> bad.
>> 
>> I think 'indirect' structs with a heuristic default are important to the way 
>> people are writing Swift in practice. We've seen many users fully invest in 
>> value semantics types, because they wants the benefits of isolated state, 
>> without appreciating the code size and performance impacts. Furthermore, 
>> implementing 'indirect' by hand is a lot of boilerplate. Putting 
>> indirectness entirely in users' hands feels to me a lot like the "value if 
>> word sized, const& if struct" heuristics C++ makes you internalize, since 
>> there are similar heuristics where 'indirect' is almost always a win in 
>> Swift too.
> 
> I understand with much of your motivation, but I still disagree with your 
> conclusion.  I see this as exactly analogous to the situation and discussion 
> when we added indirect to enums.  At the time, some argued for a magic model 
> where the compiler figured out what to do in the most common “obvious” cases. 
>  
> 
> We agreed to use our current model though because:
> 1) Better to be explicit about allocations & indirection that implicit.  
> 2) The compiler can guide the user in the “obvious” case to add the keyword 
> with a fixit, preserving the discoverability / ease of use.
> 3) When indirection is necessary, there are choices to make about where the 
> best place to do it is.
> 4) In the most common case, the “boilerplate” is a single “indirect” keyword 
> added to the enum decl itself.  In the less common case, you want the 
> “boilerplate” so that you know where the indirections are happening.
> 
> Overall, I think this model has worked well for enums and I’m still very 
> happy with it.  If you generalize it to structs, you also have to consider 
> that this should be part of a larger model that includes better support for 
> COW.  I think it would be really unfortunate to “magically indirect” struct, 
> when the right answer may actually be to COW them instead.  I’d rather have a 
> model where someone can use:
> 
> // simple, predictable, always inline, slow in some cases.
> struct S1 { … }  
> 
> And then upgrade to one of:
> 
> indirect struct S2 {…}
> cow struct S3 { … } 
> 
> Depending on the structure of their data.  In any case, to reiterate, this 
> really isn’t the time to have this debate, since it is clearly outside of 
> stage 1.

In my mind, indirect *is* cow. An indirect struct without value semantics is a 
class, so there would be no reason to implement 'indirect' for structs without 
providing copy-on-write behavior. I believe that the situation with structs and 
enums is also different. Indirecting enums has a bigger impact on interface 
because they enable recursive data structures, and while there are places where 
indirecting a struct may make new recursion possible, that's much rarer of a 
reason to introduce indirectness for structs. Performance and code size are the 
more common reasons, and we've described how to build COW boxes manually to 
work around performance problems at the last two years' WWDC. There are pretty 
good heuristics for when indirection almost always beats inline storage: once 
you have more than one refcounted field, passing around a box and retaining 
once becomes cheaper than retaining the fields individually. Once you exceed 
the fixed-sized buffer threshold of three words, indirecting some or all of 
your fields becomes necessary to avoid falling off a cliff in unspecialized 
generic or protocol-type-based code. Considering that we hope to explore other 
layout optimizations, such as automatically reordering fields to minimize 
padding, and that, as with padding, there are simple rules for indirecting that 
can be mechanically followed to get good results in the 99% case, it seems 
perfectly reasonable to me to automate this.

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

Re: [swift-evolution] [Idea] return if / return unless

[Christian Kienle via swift-evolution]

+1

2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution <
swift-evolution@swift.org>:

> How often have you written something like the following?
>
> `
> if indexPath.row == 0 { return }
>
> guard let thing = things[index] else { return nil }
> `
>
> I propose adding some syntactic sugar to make such statements more
> readable and simple to write:
>
> `
> return if indexPath.row == 0
>
> return nil unless let thing = things[index]
> `
>
> I don’t know how easy or hard this would be to implement, but I think it
> would improve some code significantly.
>
> –Julian Dunskus
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Mit freundlichen Grüßen

*Christian Kienle*
Mobile Developer

*REWE Digital GmbH*
Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender),
Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450

Telefon: +49 151 11441782
E-Mail: christian.kie...@rewe-digital.com
Internet: *www.rewe-digital.com *

Ein Unternehmen der *REWE GROUP*
http://www.rewe-group.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Max Desiatov via swift-evolution]

Hi Daniel,

I hope this proposal really is still in active review, as it is marked as such 
in the swift-evolution Git repository.

I did a quick reading of this proposal and I like it very much. I think that it 
provides a solution that is additive and doesn't break any existing package 
specifications.

With the amount of source-breaking changes in Swift, I think this proposal is 
really important and I hope that it still will be implemented in Swift 3 
timeframe. Especially as SwiftPM is not as tightly coupled with the core 
compiler infrastructure, this would be a good timing to introduce this to help 
people in transitioning from Swift 2.2 to Swift 3.

Have you previously considered also adding a field to manifests, that will 
allow to declare the supported version in the dependency manifest itself? As in:

let package =
 Package(
name: "Foo",
swiftVersions: ["3.0", "2.1"]
)

This would make it impossible to even try to build this module with Swift 2.1, 
thus saving time by not doing a build that will inevitably fail. This would 
also help packages supporting both versions in the same source tree with #ifdef 
swift version conditionals. I do realise that my suggestion will not be 
considered for Swift 3, but I look forward to your feedback on this.

Thanks!

---
With best regards, Max.

> On 29 Jul 2016, at 21:36, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0135: Package Manager Support for Differentiating Packages 
> by Swift version" begins now and runs through August 3rd. The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
> 
>   https://lists.swift.org/mailman/listinfo/swift-build-dev
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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,
> 
> - Daniel Dunbar
> Review Manager
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

[swift-evolution] [Idea] return if / return unless

[Julian Dunskus via swift-evolution]

How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more readable and 
simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it would 
improve some code significantly.

–Julian Dunskus___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[James Froggatt via swift-evolution]

> On 4 Aug 2016, at 13:00, Raphael Sebbe  wrote:
> 
> Thank you Chris, James.
> 
> I'm answering James feedback/questions below.
> 
>> On Thu, Aug 4, 2016 at 1:57 AM James Froggatt  wrote:
>> 
>> What are your thoughts on using tuples for this? 
>> 
>> typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint)
>> 
>> struct Quad { var corners: CGPoint4 }
>> 
>> var fixedLength = (point1, point2, point3, point4)
>> print(fixedLength.0)
>> print(fixedLength.4) //compiler error, not an element of the tuple
>> 
>> With shorthand declaration syntax, this would have the benefits of a 
>> fixed-length array with added compile-time safety. A previously suggested 
>> syntax was along the lines of '(CGPoint * 4)'.
>> 
> 
> I investigated tuples a bit, it's close. The one thing I'd need is being able 
> to index the values using a variable. The tuple.i notation apparently doesn't 
> work (or I did not try hard enough). Also, for low-level things that will be 
> mapped to GPU memory, precise/predictable/settable alignment is needed.

Good point. A similar mechanism might be possible eventually for tuples, but 
right now this isn't possible.

>>> 4. Reference/pointer to structs: accessing & modifying structs deep into 
>>> the model currently requires fully qualified path to the struct instance. 
>>> Fully qualifying an inner struct in your data model can be very tedious, 
>>> depending on model complexity. 
>>>  
>>> For instance, with scoped access solutions made with Swift 3, you need to 
>>> cascade blocks if you need to access multiple inner structs, which doesn't 
>>> scale well as it creates code pyramids:
>>> 
>>> scopedAccess() {  
>>>  scopedAccess() {  
>>>   // modify varA & varB  
>>>  }  
>>> }
>>>   
>>> It's easily done in C/C++ using pointers/references. To make that better, 
>>> we'd need some kind of language support IMO.
>> 
>> Could this be generalised, maybe with a reference-semantic ‘property 
>> accessor’?
>> 
>> Example:
>> 
>> let get: () -> Bool = #get(controller.view.isVisible)
>> print(get())
>> 
>> let set: (Bool) -> () = #set(controller.view.isVisible)
>> set(true)
>> 
>> let accessor: Lens = #lens(controller.view.isVisible)
>> print(accessor.value)
>> accessor.value = true
>> 
>> This would have the added bonus of also tracking the reassignment of 
>> reference-type properties - in this example, if 'view' is reassigned, the 
>> referenced value is updated.
> 
> Sounds good, I'm not aware of this syntax. Will investigate, thanks.

Sorry, I was suggesting a *possible* syntax. No such syntax currently exists, 
though the functionality can be imitated with closures:

let get: () -> Bool = {controller.view.isVisible}
print(get())

let set: (Bool) -> () = {controller.view.isVisible = $0}
set(true)

struct Lens {
  var get: () -> T
  var set: (T) -> ()
  var value: T { get { return get() } set { set(newValue) } }
}
let accessor: Lens = Lens(get: {controller.view.isVisible}, set: 
{controller.view.visible = $0})
print(accessor.value)
accessor.value = true

It's a bit more verbose when creating the get-set accessor, and may not perform 
optimally, but it's actually pretty functional.

>  
>> 
>>> 5. Memory / pointer access, including casting. It's too verbose currently 
>>> IMO when compared to C. Should be better supported for a language that is 
>>> also targeting low-level (network, disk storage). A syntax that is both 
>>> fast (like C) and safe would be great.
>> 
>> Not familiar with low-level programming in Swift, but have you considered 
>> creating domain-specific operators?
>> For example, I imagine something like 'UnsafeMutablePointer(v)' could be 
>> reduced to '*v'.
>> 
> 
> Do you mean operator is available only within a limited scope? That would be 
> interesting, because I don't want to pollute global scope with such 
> all-purpose operator. Sounds that I need to investigate that as well.

If you have a specific module which performs this sort of operation a lot, you 
can just declare the operator as internal. If it's needed in several, making a 
separate module for the operators could be preferable.

>> 
>>> 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., but 
>>> this has already been mentioned -> cool!
>> 
>> I would like to see some ideas in this area.
>> async/await never really clicked for me until I realised it's just syntactic 
>> sugar - 'await' actually ends the function, and everything below is an 
>> implicit callback. Personally I feel like Swift's trailing closure syntax 
>> makes callbacks lightweight enough that this isn't so much of an issue. 
>> Something focusing more on the memory-management and thread-safety aspects 
>> of asynchronous code does seem useful in the context of Swift.
>>> 
> Sure thread-safety, atomicity features would be really nice & useful. 
> 
> The one problem I have with closure syntax (trailing or not, I like trailing 
> too), is that when you chain a 

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Raphael Sebbe via swift-evolution]

Thank you Chris, James.

I'm answering James feedback/questions below.

On Thu, Aug 4, 2016 at 1:57 AM James Froggatt  wrote:

What are your thoughts on using tuples for this?
>
> typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint)
>
> struct Quad { var corners: CGPoint4 }
>
> var fixedLength = (point1, point2, point3, point4)
> print(fixedLength.0)
> print(fixedLength.4) //compiler error, not an element of the tuple
>
> With shorthand declaration syntax, this would have the benefits of a
> fixed-length array with added compile-time safety. A previously suggested
> syntax was along the lines of '(CGPoint * 4)'.
>
>
I investigated tuples a bit, it's close. The one thing I'd need is being
able to index the values using a variable. The tuple.i notation apparently
doesn't work (or I did not try hard enough). Also, for low-level things
that will be mapped to GPU memory, precise/predictable/settable alignment
is needed.


> 4. Reference/pointer to structs: accessing & modifying structs deep into
> the model currently requires fully qualified path to the struct instance.
> Fully qualifying an inner struct in your data model can be very tedious,
> depending on model complexity.
>
> For instance, with scoped access solutions made with Swift 3, you need to
> cascade blocks if you need to access multiple inner structs, which doesn't
> scale well as it creates code pyramids:
>
> scopedAccess() {
>  scopedAccess() {
>   // modify varA & varB
>  }
> }
>
> It's easily done in C/C++ using pointers/references. To make that better,
> we'd need some kind of language support IMO.
>
>
> Could this be generalised, maybe with a reference-semantic ‘property
> accessor’?
>
> Example:
>
> let get: () -> Bool = #get(controller.view.isVisible)
> print(get())
>
> let set: (Bool) -> () = #set(controller.view.isVisible)
> set(true)
>
> let accessor: Lens = #lens(controller.view.isVisible)
> print(accessor.value)
> accessor.value = true
>
> This would have the added bonus of also tracking the reassignment of
> reference-type properties - in this example, if 'view' is reassigned, the
> referenced value is updated.
>

Sounds good, I'm not aware of this syntax. Will investigate, thanks.



>
> 5. Memory / pointer access, including casting. It's too verbose currently
> IMO when compared to C. Should be better supported for a language that is
> also targeting low-level (network, disk storage). A syntax that is both
> fast (like C) and safe would be great.
>
>
> Not familiar with low-level programming in Swift, but have you considered
> creating domain-specific operators?
> For example, I imagine something like 'UnsafeMutablePointer(v)' could be
> reduced to '*v'.
>
>
Do you mean operator is available only within a limited scope? That would
be interesting, because I don't want to pollute global scope with such
all-purpose operator. Sounds that I need to investigate that as well.


>
> 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc.,
> but this has already been mentioned -> cool!
>
>
> I would like to see some ideas in this area.
> async/await never really clicked for me until I realised it's just
> syntactic sugar - 'await' actually ends the function, and everything below
> is an implicit callback. Personally I feel like Swift's trailing closure
> syntax makes callbacks lightweight enough that this isn't so much of an
> issue. Something focusing more on the memory-management and thread-safety
> aspects of asynchronous code does seem useful in the context of Swift.
>
>
> Sure thread-safety, atomicity features would be really nice & useful.

The one problem I have with closure syntax (trailing or not, I like
trailing too), is that when you chain a few of them, which is pretty
frequent is async programming, you end up with a closure pyramid. It
doesn't scale well beyond 2 or 3 levels.

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

Re: [swift-evolution] MemoryLayout for a value

[Boris Wang via swift-evolution]

excuse me, does this means there no sizeof(), like C language?

In C:

Struct S {}

Let x= S()

size of(S) == size of(x)


Xiaodi Wu via swift-evolution 于2016年8月4日
周四15:32写道：

> On Thu, Aug 4, 2016 at 2:29 AM, Karl  wrote:
>
>>
>> On 4 Aug 2016, at 06:27, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> on Wed Aug 03 2016, Xiaodi Wu > > wrote:
>>
>> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
>> magic altogether?
>>
>>
>> My proposal *does* drop the autoclosure magic.  `type(of: x)` is already
>> in
>> the standard library (replacing `x.dynamicType`). The reasons not to have:
>>
>>   MemoryLayout(of: x)
>>
>> where x is an arbitrary instance, is that it reads and pronounces the
>> same as
>>
>>   MemoryLayout
>>
>> but has different meaning, and even a different type (which results in
>> additional API complexity—the forwarding vars I showed in the [Aside]
>> box from my previous post).  Imagine explaining the difference between
>> these two in that world:
>>
>>   MemoryLayout
>>   MemoryLayout(of: Int.self)
>>
>> The first is a type representing the layout of Int.  The second is an
>> instance of that type representing the layout of Int's metatype.
>>
>>
>> It’s confusing because metatypes in Swift are pretty confusing in
>> general: Int.self returns Int.Type which is not the same as `type(of: > Int>)` (that would be Int).
>>
>> If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
>> Int.self) would return a MemoryLayout.
>>
>
> Yes, here, I agree Dave is absolutely right. You and Dave have convinced
> me that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is
> an instance, would be appropriate.
>
>> The classic sizeofValue evaluated its argument, and in Foundation several
>> uses of it actually relied on that side effect. While autoclosures are
>> quite clever, in general I think the user expectation is that given
>> `a(b(c))` both a and b are invoked, side effects and all.
>>
>> Note that both type(of:) as it's currently implemented and the old
>> dynamicType evaluate its argument/receiver.
>>
>>
>> I didn't realize that, but it's fine.  I'm attached to the use of
>> `type(of:)` in this idiom, not to having an autoclosure involved.
>>
>> No one afaik has ever thought that behavior to be anomalous (though I
>> bet we're about to hear some arguments to that effect now).
>>
>> On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> Having seen the effects in the standard library and in other
>> code, I'm concerned that we may have made a mistake in removing
>> `sizeofValue` et al without providing a replacement.  In the standard
>> library, we ended up adding an underscored API that allows
>>
>>  MemoryLayout._ofInstance(someExpression).size
>>
>> Where someExpression is an autoclosure, and thus not evaluated.  I
>> wanted to bring up the possibility of introducing a replacement as a
>> bufix.
>>
>> I propose that the way to express the above should be:
>>
>>  MemoryLayout.of(type(of: someExpression)).size
>>
>> implementable as:
>>
>>  extension MemoryLayout {
>>@_transparent
>>public
>>static func of(_: T.Type) -> MemoryLayout.Type {
>>  return MemoryLayout.self
>>}
>>  }
>>
>> I think this API would solve the concerns I had about confusability that
>> led me to advocate dropping the ability to ask for the size of a value.
>> The only way to use it is to pass a type and these two expressions have
>> equivalent meaning:
>>
>>MemoryLayout
>>MemoryLayout.of(Int.self)
>>
>> It also has the benefit of isolating the autoclosure magic to type(of:).
>>
>> ,[ Aside ]
>> | A slightly cleaner use site is possible with a larger API change:
>> |
>> |   MemoryLayout(type(of: someExpression)).size
>> |
>> | Which would involve changing MemoryLayout from an `enum` to
>> | a `struct` and adding the following:
>> |
>> |   extension MemoryLayout {
>> | public init(_: T.Type) {}
>> |
>> | public var size: Int { return MemoryLayout.size }
>> | public var stride: Int { return MemoryLayout.stride }
>> | public var alignment: Int { return MemoryLayout.alignment }
>> |   }
>> |
>> | However I am concerned that dropping ".of" at the use site is worth the
>> | added API complexity.
>> `
>>
>> Thoughts?
>> --
>> -Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> --
>> -Dave
>> ___
>> 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] [Swift4] Mailing list vs. Forum

[Johannes Neubauer via swift-evolution]

+1 for Discourse.

It is much more accessible. When I subscribed to swift-evolution I was curious 
how bigger discussions would work since I used mailing-lists only for small 
teams yet. After some replies to a thread it started to get really ugly to 
quote relevant parts of several old posts and to keep track of all the 
information (not only for me which leads to unnecessary misunderstandings). 
Further on, it is very time-consuming to filter the information that you want 
to have. Features like „watch“ a thread help to customize for which threads I 
would like to retrieve emails or not.

Github itself uses this for issues, too. If you create an issue, you will get 
mail. You can unsubscribe to the issue. You can subscribe to issues you are 
interested in. You can click on a link in the mail leading directly to the 
corresponding comment in the issue.

All the best
Johannes

> Am 04.08.2016 um 05:34 schrieb Brandon Knope via swift-evolution 
> :
> 
> Using Apple Developer Forums would cause people to leave swift-evolution (a 
> prediction). I don’t think they offer a good enough experience for quick 
> discussions like mailing lists or Discourse do.
> 
> My question is: would we gain more people than we would lose in moving over 
> to something like Discourse?
> 
> I don’t think a lot of people on here are grasping the high burden mailing 
> lists place on people not familiar with them
> 
> Brandon
> 
>> On Aug 3, 2016, at 10:02 PM, Paulo Faria via swift-evolution 
>>  wrote:
>> 
>> Exactly what I was going to say. Why not use Apple’s forum?
>> It’s there already. It’s just a matter of using it. Some are saying things 
>> like, the core team should be focused on working on the language, etc. 
>> That’s so obvious that it shouldn’t even be said. This is a fact, but a fact 
>> that has nothing to do with having a good communication medium. It’s just a 
>> matter of decision. The core team could decide we use apple’s forum instead 
>> of the mailing list, boom, done. If we need any extra features from the 
>> forum, it’s not gonna be the core team to deal with. It will be the people 
>> that are already responsible for the apple forum.
>> 
>>> On Aug 3, 2016, at 6:47 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> I did not have the time to counter all those points but I was going to and 
>>> point that Discourse has a solution for nearly all of those. I would REALLY 
>>> prefer having the mailing-list part of the discussion on Discourse.
>>> 
 On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution 
  wrote:
 
 I hope my replies aren't too curt — I don't want to pick a fight (any more 
 than I did by starting this topic), but to explore how Discourse can serve 
 these use cases. Feel free to re-rebut.
 
 On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon 
  wrote:
 
 I don't think enough has been said in favor of mailing lists. Some 
 advantages for them:
 
 1. Available on every platform.
 Browsers too.
 
 
 2. Performant on every platform. (Discourse, for instance, struggles on 
 Android.)
 Browsers are heavily tuned for performance, and Discourse is a relatively 
 lightweight site. If you prefer the performance of your email client, 
 there's mailing list mode.
 
 
 3. Native on every platform.
 Browsers too.
 
 
 4. Based on open standards with multiple implementations.
 Browsers too. You may argue that the forum itself is too centralized, but 
 Mailman is necessarily centralized too.
 
 And this isn't always a positive: formatting of styled, quoted, and even 
 plain text is quite varied among email clients, so popular threads often 
 end up looking like huge messes.
 
 
 5. Does not require you to proactively check swift-evolution.
 Email notification settings, or full-on mailing list mode, or RSS, can 
 solve this.
 
 
 6. Supports offline reading and drafting.
 Mailing list mode or RSS / reply-by-email.
 
 
 7. Supports clients with alternate feature sets.
 Discourse has RSS feeds and JSON APIs.
 
 
 8. Supports bot clients for both sending (like the CI bot) and receiving 
 (like Gmane).
 Discourse has an API which can be used for posting. It also supports 
 bot-like plugins which can respond to various events, although I imagine 
 that requires self-hosting. External bots interested in receiving would 
 probably need to poll RSS, or just make use of mailing list mode as a 
 receive hook.
 
 
 9. Supports user-specific automatic filtering.
 Topics and categories in Discourse each support a range of notification 
 options from "watching" to "muted". My understanding is that these 
 settings are respected 

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Thu, Aug 4, 2016 at 2:29 AM, Karl  wrote:

>
> On 4 Aug 2016, at 06:27, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Wed Aug 03 2016, Xiaodi Wu  > wrote:
>
> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
> magic altogether?
>
>
> My proposal *does* drop the autoclosure magic.  `type(of: x)` is already in
> the standard library (replacing `x.dynamicType`). The reasons not to have:
>
>   MemoryLayout(of: x)
>
> where x is an arbitrary instance, is that it reads and pronounces the
> same as
>
>   MemoryLayout
>
> but has different meaning, and even a different type (which results in
> additional API complexity—the forwarding vars I showed in the [Aside]
> box from my previous post).  Imagine explaining the difference between
> these two in that world:
>
>   MemoryLayout
>   MemoryLayout(of: Int.self)
>
> The first is a type representing the layout of Int.  The second is an
> instance of that type representing the layout of Int's metatype.
>
>
> It’s confusing because metatypes in Swift are pretty confusing in general:
> Int.self returns Int.Type which is not the same as `type(of: )`
> (that would be Int).
>
> If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
> Int.self) would return a MemoryLayout.
>

Yes, here, I agree Dave is absolutely right. You and Dave have convinced me
that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is an
instance, would be appropriate.

> The classic sizeofValue evaluated its argument, and in Foundation several
> uses of it actually relied on that side effect. While autoclosures are
> quite clever, in general I think the user expectation is that given
> `a(b(c))` both a and b are invoked, side effects and all.
>
> Note that both type(of:) as it's currently implemented and the old
> dynamicType evaluate its argument/receiver.
>
>
> I didn't realize that, but it's fine.  I'm attached to the use of
> `type(of:)` in this idiom, not to having an autoclosure involved.
>
> No one afaik has ever thought that behavior to be anomalous (though I
> bet we're about to hear some arguments to that effect now).
>
> On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Having seen the effects in the standard library and in other
> code, I'm concerned that we may have made a mistake in removing
> `sizeofValue` et al without providing a replacement.  In the standard
> library, we ended up adding an underscored API that allows
>
>  MemoryLayout._ofInstance(someExpression).size
>
> Where someExpression is an autoclosure, and thus not evaluated.  I
> wanted to bring up the possibility of introducing a replacement as a
> bufix.
>
> I propose that the way to express the above should be:
>
>  MemoryLayout.of(type(of: someExpression)).size
>
> implementable as:
>
>  extension MemoryLayout {
>@_transparent
>public
>static func of(_: T.Type) -> MemoryLayout.Type {
>  return MemoryLayout.self
>}
>  }
>
> I think this API would solve the concerns I had about confusability that
> led me to advocate dropping the ability to ask for the size of a value.
> The only way to use it is to pass a type and these two expressions have
> equivalent meaning:
>
>MemoryLayout
>MemoryLayout.of(Int.self)
>
> It also has the benefit of isolating the autoclosure magic to type(of:).
>
> ,[ Aside ]
> | A slightly cleaner use site is possible with a larger API change:
> |
> |   MemoryLayout(type(of: someExpression)).size
> |
> | Which would involve changing MemoryLayout from an `enum` to
> | a `struct` and adding the following:
> |
> |   extension MemoryLayout {
> | public init(_: T.Type) {}
> |
> | public var size: Int { return MemoryLayout.size }
> | public var stride: Int { return MemoryLayout.stride }
> | public var alignment: Int { return MemoryLayout.alignment }
> |   }
> |
> | However I am concerned that dropping ".of" at the use site is worth the
> | added API complexity.
> `
>
> Thoughts?
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
> -Dave
> ___
> 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] MemoryLayout for a value

[Karl via swift-evolution]

> On 4 Aug 2016, at 06:27, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Aug 03 2016, Xiaodi Wu  > wrote:
> 
>> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
>> magic altogether?
> 
> My proposal *does* drop the autoclosure magic.  `type(of: x)` is already in
> the standard library (replacing `x.dynamicType`). The reasons not to have:
> 
>   MemoryLayout(of: x)
> 
> where x is an arbitrary instance, is that it reads and pronounces the
> same as
> 
>   MemoryLayout
> 
> but has different meaning, and even a different type (which results in
> additional API complexity—the forwarding vars I showed in the [Aside]
> box from my previous post).  Imagine explaining the difference between
> these two in that world:
> 
>   MemoryLayout
>   MemoryLayout(of: Int.self)
> 
> The first is a type representing the layout of Int.  The second is an
> instance of that type representing the layout of Int's metatype.
> 

It’s confusing because metatypes in Swift are pretty confusing in general: 
Int.self returns Int.Type which is not the same as `type(of: )` (that 
would be Int).

If a novice wants to jump in, they’ll have to know that MemoryLayout(of: 
Int.self) would return a MemoryLayout.

>> The classic sizeofValue evaluated its argument, and in Foundation several
>> uses of it actually relied on that side effect. While autoclosures are
>> quite clever, in general I think the user expectation is that given
>> `a(b(c))` both a and b are invoked, side effects and all.
>> 
>> Note that both type(of:) as it's currently implemented and the old
>> dynamicType evaluate its argument/receiver. 
> 
> I didn't realize that, but it's fine.  I'm attached to the use of
> `type(of:)` in this idiom, not to having an autoclosure involved.
> 
>> No one afaik has ever thought that behavior to be anomalous (though I
>> bet we're about to hear some arguments to that effect now).  
>> 
>> On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> 
>>> 
>>> Having seen the effects in the standard library and in other
>>> code, I'm concerned that we may have made a mistake in removing
>>> `sizeofValue` et al without providing a replacement.  In the standard
>>> library, we ended up adding an underscored API that allows
>>> 
>>>  MemoryLayout._ofInstance(someExpression).size
>>> 
>>> Where someExpression is an autoclosure, and thus not evaluated.  I
>>> wanted to bring up the possibility of introducing a replacement as a
>>> bufix.
>>> 
>>> I propose that the way to express the above should be:
>>> 
>>>  MemoryLayout.of(type(of: someExpression)).size
>>> 
>>> implementable as:
>>> 
>>>  extension MemoryLayout {
>>>@_transparent
>>>public
>>>static func of(_: T.Type) -> MemoryLayout.Type {
>>>  return MemoryLayout.self
>>>}
>>>  }
>>> 
>>> I think this API would solve the concerns I had about confusability that
>>> led me to advocate dropping the ability to ask for the size of a value.
>>> The only way to use it is to pass a type and these two expressions have
>>> equivalent meaning:
>>> 
>>>MemoryLayout
>>>MemoryLayout.of(Int.self)
>>> 
>>> It also has the benefit of isolating the autoclosure magic to type(of:).
>>> 
>>> ,[ Aside ]
>>> | A slightly cleaner use site is possible with a larger API change:
>>> |
>>> |   MemoryLayout(type(of: someExpression)).size
>>> |
>>> | Which would involve changing MemoryLayout from an `enum` to
>>> | a `struct` and adding the following:
>>> |
>>> |   extension MemoryLayout {
>>> | public init(_: T.Type) {}
>>> |
>>> | public var size: Int { return MemoryLayout.size }
>>> | public var stride: Int { return MemoryLayout.stride }
>>> | public var alignment: Int { return MemoryLayout.alignment }
>>> |   }
>>> |
>>> | However I am concerned that dropping ".of" at the use site is worth the
>>> | added API complexity.
>>> `
>>> 
>>> Thoughts?
>>> --
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
> 
> -- 
> -Dave
> ___
> 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] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Wed, Aug 3, 2016 at 11:27 PM, Dave Abrahams  wrote:

>
> on Wed Aug 03 2016, Xiaodi Wu  wrote:
>
> > Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
> > magic altogether?
>
> My proposal *does* drop the autoclosure magic.  `type(of: x)` is already in
> the standard library (replacing `x.dynamicType`). The reasons not to have:
>
>MemoryLayout(of: x)
>
> where x is an arbitrary instance, is that it reads and pronounces the
> same as
>
>MemoryLayout
>
> but has different meaning, and even a different type (which results in
> additional API complexity—the forwarding vars I showed in the [Aside]
> box from my previous post).  Imagine explaining the difference between
> these two in that world:
>
>MemoryLayout
>MemoryLayout(of: Int.self)
>
> The first is a type representing the layout of Int.  The second is an
> instance of that type representing the layout of Int's metatype.
>
> > The classic sizeofValue evaluated its argument, and in Foundation several
> > uses of it actually relied on that side effect. While autoclosures are
> > quite clever, in general I think the user expectation is that given
> > `a(b(c))` both a and b are invoked, side effects and all.
> >
> > Note that both type(of:) as it's currently implemented and the old
> > dynamicType evaluate its argument/receiver.
>
> I didn't realize that, but it's fine.  I'm attached to the use of
> `type(of:)` in this idiom, not to having an autoclosure involved.
>

Your proposed `.of(type(of: x)).size` differs from the original
`sizeofValue()` in at least one other way--is this in fact *why* you're
proposing the change? In the classic syntax:

```
protocol P { }
print(sizeof(P.self)) // 40

struct S : P {
  let x = 2
}
print(sizeof(S.self)) // 8

var a: P = S()
print(a.dynamicType) // S
print(sizeofValue(a)) // 40
```

> No one afaik has ever thought that behavior to be anomalous (though I
> > bet we're about to hear some arguments to that effect now).
> >
> > On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
> > swift-evolution@swift.org> wrote:
> >
> >>
> >> Having seen the effects in the standard library and in other
> >> code, I'm concerned that we may have made a mistake in removing
> >> `sizeofValue` et al without providing a replacement.  In the standard
> >> library, we ended up adding an underscored API that allows
> >>
> >>   MemoryLayout._ofInstance(someExpression).size
> >>
> >> Where someExpression is an autoclosure, and thus not evaluated.  I
> >> wanted to bring up the possibility of introducing a replacement as a
> >> bufix.
> >>
> >> I propose that the way to express the above should be:
> >>
> >>   MemoryLayout.of(type(of: someExpression)).size
> >>
> >> implementable as:
> >>
> >>   extension MemoryLayout {
> >> @_transparent
> >> public
> >> static func of(_: T.Type) -> MemoryLayout.Type {
> >>   return MemoryLayout.self
> >> }
> >>   }
> >>
> >> I think this API would solve the concerns I had about confusability that
> >> led me to advocate dropping the ability to ask for the size of a value.
> >> The only way to use it is to pass a type and these two expressions have
> >> equivalent meaning:
> >>
> >> MemoryLayout
> >> MemoryLayout.of(Int.self)
> >>
> >> It also has the benefit of isolating the autoclosure magic to type(of:).
> >>
> >> ,[ Aside ]
> >> | A slightly cleaner use site is possible with a larger API change:
> >> |
> >> |   MemoryLayout(type(of: someExpression)).size
> >> |
> >> | Which would involve changing MemoryLayout from an `enum` to
> >> | a `struct` and adding the following:
> >> |
> >> |   extension MemoryLayout {
> >> | public init(_: T.Type) {}
> >> |
> >> | public var size: Int { return MemoryLayout.size }
> >> | public var stride: Int { return MemoryLayout.stride }
> >> | public var alignment: Int { return MemoryLayout.alignment }
> >> |   }
> >> |
> >> | However I am concerned that dropping ".of" at the use site is worth
> the
> >> | added API complexity.
> >> `
> >>
> >> Thoughts?
> >> --
> >> -Dave
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
>
> --
> -Dave
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Wed, Aug 3, 2016 at 11:32 PM, Dave Abrahams  wrote:

>
> on Wed Aug 03 2016, Xiaodi Wu  wrote:
>
> > Agreed, but I do think "memory layout of type of my value, size" is a
> > mouthful compared to "size of value".
>
> It is, but it would avoid confusion.
>
> > Moreover, something doesn't sit right with me that MemoryLayout and
> > MemoryLayout.of(T.self) would be one and the same thing.
>
> As far as I'm concerned, that's a feature, not a bug.  Unless you can
> describe why it should be different, “it doesn't sit right” is not a
> helpful argument.
>

Originally, I'd actually half-way typed out a fuller argument, then deleted
it, assuming most would find it to be uninteresting due to obviousness.
Let's see:

Unless I'm mistaken, every place where one might write `MemoryLayout`
can be replaced with `MemoryLayout.of(T.self)`. (Yes, I understand that
there are places where substituting in the other direction would be
unsatisfactory, hence this follow-up thread.) However, I understand it to
be a bug, not a feature, to have two different ways of spelling the same
thing, because it necessarily brings confusion as to why there must be two
of them, and I therefore consider this proposed design to be suboptimal.
You titled this thread "MemoryLayout for a value": I agree that that's what
we need. It ought to be possible to provide facilities for exactly that
*without* also providing an entirely duplicative way of spelling
MemoryLayout for a type.

> Could I suggest an alternative? It's conservative in that it mimics the
> > relationships we had before the proposal was implemented and also
> maintains
> > the simplicity of the caseless enum:
> >
> > ```
> > extension MemoryLayout {
> >   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
> >   // etc.
> > }
> > ```
>
> That introduces even more potential for confusion than adding forwarding
> vars to instances does.  Now you're talking about “overloading” a static
> property with a static method having the same base name.
>

IMO, here's where it's a feature, not a bug. I propose `size(ofValue:)` and
`size` because they *are* related, just like how `first(where:)` and
`first` are related for a Collection. Moreover, the whole thing reads
exactly as it should (and, not by accident, nearly identically to this
thread's subject line): "memory layout size of value x". What is the source
of confusion that you think would arise from this pseudo-overloading, and
why are you emphasizing the fact that both would be static
properties/methods (is it less confusing when it's not static)?


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

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

[Haravikk via swift-evolution]

> On 4 Aug 2016, at 03:19, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via swift-evolution 
>>  wrote:
>> 
>> I was wondering why this would put any more of a burden on the runtime
>> than simple inheritance of protocols. The way this could be
>> implemented is to augment the ConformanceTable for nominal types by
>> looking up its protocol extension’s inheritance clauses. I can
>> definitely see this impacting compile time but I don’t see why runtime
>> performance will be any different than simple inheritance. Further,
>> cyclic chains can be detected and broken (compiler error) during the
>> second pass of semantic analysis.
> 
> My understanding—which may be incorrect, by the way—is that the issue is 
> mainly with protocol extensions adding conformances, not specifically with 
> those conformances being conditional, and that it specifically has to do with 
> `is` and `as?` checks across module boundaries.
> 
> Suppose you have these declarations in module M:
> 
>   public protocol AProtocol {…}
>   public protocol BProtocol: AProtocol {…}
>   public protocol CProtocol {…}
>   
>   // Public or otherwise doesn't matter here.
>   public struct Foo: BProtocol {…}
> 
> Foo essentially has a flat list of the protocols it conforms to attached to 
> it. Notionally, you can think of that list as looking like:
> 
>   Foo.self.conformsTo = [BProtocol.self, AProtocol.self]
> 
> And when you write `foo is CProtocol`, that eventually translates into:
> 
>   foo.dynamicType.conformsTo.contains(CProtocol.self)
> 
> For a `Foo`, since the `conformsTo` list doesn't include `CProtocol.self`, it 
> returns `false`.
> 
> Now imagine that you write a new module, N, and in it you say:
> 
>   extension Foo: CProtocol {…}
> 
> You have now retroactively conformed `Foo` to `CProtocol`. Swift needs to 
> reach into module M and add `CProtocol.self` to the `Foo.self.conformsTo` 
> list. This is perfectly doable for a concrete type—it's one flat list, after 
> all.
> 
> Instead, though, imagine that module N extended `AProtocol` to add a 
> conformance:
> 
>   extension AProtocol: CProtocol {…}
> 
> There are two ways to handle this. One is to find all types conforming to 
> `AProtocol`, recursively, and add `CProtocol.self` to their conformance list. 
> The other is to scrap the flat list of conformances and instead make `is` and 
> `as?` recursively search each protocol. Either way, you have replaced a fast, 
> flat operation with a slow, recursive one.
> 
> Conditional conformance adds another wrinkle to this, of course—you must not 
> only recursively search the list, but also evaluate the condition to see if 
> it applies in this case. But the general problem of having to replace a fast 
> search with a slow search applies either way.

Great explanation! This switch from flat to recursively searched though seems 
like it would only occur when the extension is in an external module though; 
for internal modules would it not still be possible to determine the flat list 
for each type? In that case extending a type from another module could be 
either disallowed, or produce a warning to indicate the performance implication?

The feature would still be very useful even just for internal use after all. 
Also it seems useful on a relatively small number of types, and the number of 
external modules that need/want to do this must narrow that even further, so 
external extensions may be quite niche, i.e- not worth losing the feature for 
internal use if that is indeed easier?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Goffredo Marocchi via swift-evolution]

While I understand both your position and Joe's one, I think that it is good if 
in the Swift community at large, outside of this mailing list itself, more 
thought was given also to the side effects / losses in moving everything over 
to value types over references (one could have said with careful use of copy 
constructors and other solutions reference types can be tamed so why bother 
with value type renaissance? People seemed to make a lot of production code 
before...) and how those can and should be tamed.

Value types and the impact on performance (copies were advertised as almost 
free in Dave's talks but even when implementing CoW smartly like you have done 
with Array, Dictionary, etc... this still may mean surprising large copies 
happening at times some users may not expect them to be). 

Regardless of the outcome I still see debate on this and putting yesterday's 
values to the test of today's data and knowledge pragmatic and it should not be 
seen as raining on the language's parade :).

Sorry for the rant-ish nature of my reply.

Sent from my iPhone

> On 4 Aug 2016, at 04:46, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
> 
> a. We indirect automatically based on some heuristic, as an
> optimization.
>>> 
>>> I weakly disagree with this, because it is important that we provide a 
>>> predictable model.  I’d rather the user get what they write, and tell 
>>> people to write ‘indirect’ as a performance tuning option.  “Too magic” is 
>>> bad.
>> 
>> I think 'indirect' structs with a heuristic default are important to the way 
>> people are writing Swift in practice. We've seen many users fully invest in 
>> value semantics types, because they wants the benefits of isolated state, 
>> without appreciating the code size and performance impacts. Furthermore, 
>> implementing 'indirect' by hand is a lot of boilerplate. Putting 
>> indirectness entirely in users' hands feels to me a lot like the "value if 
>> word sized, const& if struct" heuristics C++ makes you internalize, since 
>> there are similar heuristics where 'indirect' is almost always a win in 
>> Swift too.
> 
> I understand with much of your motivation, but I still disagree with your 
> conclusion.  I see this as exactly analogous to the situation and discussion 
> when we added indirect to enums.  At the time, some argued for a magic model 
> where the compiler figured out what to do in the most common “obvious” cases. 
>  
> 
> We agreed to use our current model though because:
> 1) Better to be explicit about allocations & indirection that implicit.  
> 2) The compiler can guide the user in the “obvious” case to add the keyword 
> with a fixit, preserving the discoverability / ease of use.
> 3) When indirection is necessary, there are choices to make about where the 
> best place to do it is.
> 4) In the most common case, the “boilerplate” is a single “indirect” keyword 
> added to the enum decl itself.  In the less common case, you want the 
> “boilerplate” so that you know where the indirections are happening.
> 
> Overall, I think this model has worked well for enums and I’m still very 
> happy with it.  If you generalize it to structs, you also have to consider 
> that this should be part of a larger model that includes better support for 
> COW.  I think it would be really unfortunate to “magically indirect” struct, 
> when the right answer may actually be to COW them instead.  I’d rather have a 
> model where someone can use:
> 
> // simple, predictable, always inline, slow in some cases.
> struct S1 { … }  
> 
> And then upgrade to one of:
> 
> indirect struct S2 {…}
> cow struct S3 { … } 
> 
> Depending on the structure of their data.  In any case, to reiterate, this 
> really isn’t the time to have this debate, since it is clearly outside of 
> stage 1.
> 
> -Chris
> ___
> 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] [swift-dev] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Importing the right version of a module (such as the standard library) when
more than one are available is just a search-paths problem. Supporting
multiple versions of the language's syntax and ABI, though, as far as I can
tell, requires the switch to be deeply baked into the compiler.

So I don't really see how we can get away with a "general" solution, beyond
perhaps some SwiftPM support for libraries that provide source or binaries
for multiple language versions.

On Wed, Aug 3, 2016 at 12:44 PM, Douglas Gregor  wrote:

>
> > On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev <
> swift-...@swift.org> wrote:
> >
> >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>  • a top-of-file "shebang"-style comment indicating the version,
> something like //#swift(4), mirroring the "#if swift" syntax
> >
> > `import Swift 3.1`?
> >
> > I think this brings up two interesting questions:
> >
> > * Do we want to be able to mix files using different versions of Swift
> in the same module?
>
> No. It simplifies the problem greatly if the whole module is compiled with
> a single Swift version.
>
> > * Do we want to extend these backwards compatibility features beyond the
> standard library to other modules?
>
> If we can design generally-useful features for handling language
> versioning, that the standard library can adopt, that would be great.
>
> - Doug
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Wed Aug 03 2016, Xiaodi Wu  wrote:

> Agreed, but I do think "memory layout of type of my value, size" is a
> mouthful compared to "size of value". 

It is, but it would avoid confusion.

> Moreover, something doesn't sit right with me that MemoryLayout and
> MemoryLayout.of(T.self) would be one and the same thing.

As far as I'm concerned, that's a feature, not a bug.  Unless you can
describe why it should be different, “it doesn't sit right” is not a
helpful argument.

> Could I suggest an alternative? It's conservative in that it mimics the
> relationships we had before the proposal was implemented and also maintains
> the simplicity of the caseless enum:
>
> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```

That introduces even more potential for confusion than adding forwarding
vars to instances does.  Now you're talking about “overloading” a static
property with a static method having the same base name.

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

Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Wed Aug 03 2016, Xiaodi Wu  wrote:

> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
> magic altogether?

My proposal *does* drop the autoclosure magic.  `type(of: x)` is already in
the standard library (replacing `x.dynamicType`). The reasons not to have:

   MemoryLayout(of: x)

where x is an arbitrary instance, is that it reads and pronounces the
same as

   MemoryLayout

but has different meaning, and even a different type (which results in
additional API complexity—the forwarding vars I showed in the [Aside]
box from my previous post).  Imagine explaining the difference between
these two in that world:

   MemoryLayout
   MemoryLayout(of: Int.self)

The first is a type representing the layout of Int.  The second is an
instance of that type representing the layout of Int's metatype.
 
> The classic sizeofValue evaluated its argument, and in Foundation several
> uses of it actually relied on that side effect. While autoclosures are
> quite clever, in general I think the user expectation is that given
> `a(b(c))` both a and b are invoked, side effects and all.
>
> Note that both type(of:) as it's currently implemented and the old
> dynamicType evaluate its argument/receiver. 

I didn't realize that, but it's fine.  I'm attached to the use of
`type(of:)` in this idiom, not to having an autoclosure involved.

> No one afaik has ever thought that behavior to be anomalous (though I
> bet we're about to hear some arguments to that effect now).  
>
> On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> Having seen the effects in the standard library and in other
>> code, I'm concerned that we may have made a mistake in removing
>> `sizeofValue` et al without providing a replacement.  In the standard
>> library, we ended up adding an underscored API that allows
>>
>>   MemoryLayout._ofInstance(someExpression).size
>>
>> Where someExpression is an autoclosure, and thus not evaluated.  I
>> wanted to bring up the possibility of introducing a replacement as a
>> bufix.
>>
>> I propose that the way to express the above should be:
>>
>>   MemoryLayout.of(type(of: someExpression)).size
>>
>> implementable as:
>>
>>   extension MemoryLayout {
>> @_transparent
>> public
>> static func of(_: T.Type) -> MemoryLayout.Type {
>>   return MemoryLayout.self
>> }
>>   }
>>
>> I think this API would solve the concerns I had about confusability that
>> led me to advocate dropping the ability to ask for the size of a value.
>> The only way to use it is to pass a type and these two expressions have
>> equivalent meaning:
>>
>> MemoryLayout
>> MemoryLayout.of(Int.self)
>>
>> It also has the benefit of isolating the autoclosure magic to type(of:).
>>
>> ,[ Aside ]
>> | A slightly cleaner use site is possible with a larger API change:
>> |
>> |   MemoryLayout(type(of: someExpression)).size
>> |
>> | Which would involve changing MemoryLayout from an `enum` to
>> | a `struct` and adding the following:
>> |
>> |   extension MemoryLayout {
>> | public init(_: T.Type) {}
>> |
>> | public var size: Int { return MemoryLayout.size }
>> | public var stride: Int { return MemoryLayout.stride }
>> | public var alignment: Int { return MemoryLayout.alignment }
>> |   }
>> |
>> | However I am concerned that dropping ".of" at the use site is worth the
>> | added API complexity.
>> `
>>
>> Thoughts?
>> --
>> -Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

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

Re: [swift-evolution] Improved value and move semantics

[Dave Abrahams via swift-evolution]

on Wed Aug 03 2016, Chris Lattner  wrote:

>> On Aug 3, 2016, at 8:46 PM, Chris Lattner via swift-evolution
>>  wrote:
>> 
>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>> 
>
>> a. We indirect automatically based on some heuristic, as an
>> optimization.
 
 I weakly disagree with this, because it is important that we
 provide a predictable model.  I’d rather the user get what they
 write, and tell people to write ‘indirect’ as a performance tuning
 option.  “Too magic” is bad.
>>> 
>>> I think 'indirect' structs with a heuristic default are important
>>> to the way people are writing Swift in practice. We've seen many
>>> users fully invest in value semantics types, because they wants the
>>> benefits of isolated state, without appreciating the code size and
>>> performance impacts. Furthermore, implementing 'indirect' by hand
>>> is a lot of boilerplate. Putting indirectness entirely in users'
>>> hands feels to me a lot like the "value if word sized, const& if
>>> struct" heuristics C++ makes you internalize, since there are
>>> similar heuristics where 'indirect' is almost always a win in Swift
>>> too.
>> 
>> I understand with much of your motivation, but I still disagree with your 
>> conclusion.
>
> ^I understand and agree with much of your motivation...
>
> -Chris
>
>>  I see this as exactly analogous to the situation and discussion
>> when we added indirect to enums.  At the time, some argued for a
>> magic model where the compiler figured out what to do in the most
>> common “obvious” cases.
>> 
>> We agreed to use our current model though because:
>> 1) Better to be explicit about allocations & indirection that implicit.  
>> 2) The compiler can guide the user in the “obvious” case to add the
>> keyword with a fixit, preserving the discoverability / ease of use.
>> 3) When indirection is necessary, there are choices to make about
>> where the best place to do it is.
>> 4) In the most common case, the “boilerplate” is a single “indirect”
>> keyword added to the enum decl itself.  In the less common case, you
>> want the “boilerplate” so that you know where the indirections are
>> happening.
>> 
>> Overall, I think this model has worked well for enums and I’m still
>> very happy with it.  If you generalize it to structs, you also have
>> to consider that this should be part of a larger model that includes
>> better support for COW.  I think it would be really unfortunate to
>> “magically indirect” struct, when the right answer may actually be
>> to COW them instead.  

COW'ing the struct is implied by indirecting it.  You're not allowed to
break its value semantics just because it's being stored indirectly, and
we're darned sure not going to introduce an eagerly copied box there; I
think we all agree that the eager boxes we currently have must evolve
into COWs before ABI stability sets in.

>> I’d rather have a model where someone can use:
>> 
>> // simple, predictable, always inline, slow in some cases.
>> struct S1 { … }  
>> 
>> And then upgrade to one of:
>> 
>> indirect struct S2 {…}
>> cow struct S3 { … } 
>> 
>> Depending on the structure of their data.  In any case, to
>> reiterate, this really isn’t the time to have this debate, since it
>> is clearly outside of stage 1.

Well, I don't want to draw it out either, but I do want to add one
point: the “predictable performance” argument rings pretty hollow for
me.  There are already hard-to-anticipate performance cliffs wherever we
have an inline buffer (e.g. existentials), an opportunity for stack
promotion, or where we mutate a COW data structure that might turn out
to have non-uniquely-referenced storage.  All of these effects add up to
code that performs well without too much intervention in most cases. We
should continue to make Swift perform well automatically, and give
people the tools they need to make adjustments when profiling reveals an
issue.

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