Re: [swift-evolution] Renaming for Protocol Conformance

[Chris Lattner via swift-evolution]

On Sep 6, 2016, at 6:06 PM, Jonathan Hull via swift-evolution 
 wrote:
>> I'm not entirely sure on my position, though. To be convinced otherwise, I'd 
>> need to see a compelling real-world use case that demonstrates all of the 
>> following:
>> 
>> - Safety: perhaps, with protocols, unlike class inheritance, it is almost 
>> always safe to make these kinds of changes unanticipated by the original 
>> author--it would be good to see evidence either way
> 
> You may find this paper interesting:
> http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf 
> 
> 
> It discusses traits, which are basically Swift’s protocols, plus the ability 
> to handle conflicts.  It discusses at length the issues that arise with other 
> systems.
> 
> This is a very common problem that only a few programming languages have 
> found successful solutions to.  I would also point you to Eiffel’s model for 
> multiple inheritance (select, rename, undefine, export).  I think if we keep 
> working on it, we can find a uniquely swift-feeling solution which solves the 
> issue :-)

Here’s another obscure paper coming from the world of C++, see section 3.5/4.1:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.129

Not a syntax that we would want to emulate, but it’s the same idea in different 
clothes.  The Swift implementation model should support implementing something 
along these lines, but it would be a purely additive feature.

-Chris

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

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

It'd be great to see swift.org as just another repo on github.com/apple via
GitHub Pages ;-)

Jacob

On Tue, Sep 6, 2016 at 8:45 PM, Jordan Rose  wrote:

>
> > On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> >> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch 
> wrote:
> >>
> >> Is it possible to have a repo named apple.github.io, and still allow
> individual repos having their own pages (like apple.github.io/swift-
> evolution)?
> >
> > The `username.github.io` and `username.github.io/projectname`
> combination works for me.
> >
> > The `orgname.github.io` and `orgname.github.io/projectname` combination
> should also work (but I haven't tried it).
> >
> > 
> >
> > — Ben
>
> Thanks for the suggestion, Ben. After a bit of discussion we’ve put in a
> redirect to github.com/apple/, which is definitely better than just
> 404ing.
>
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Renaming for Protocol Conformance

[Xiaodi Wu via swift-evolution]

On Tue, Sep 6, 2016 at 8:06 PM, Jonathan Hull  wrote:

>
> I argue the same thing applies here. Currently, protocols constrain the
> API of conforming types. If a designer has reasoned through their design
> correctly, then all is well. If a designer has made bad design choices,
> then conforming types are constrained to have bad API design. Is that a bug
> or a feature? It is of course a bug on the part of the designer for having
> designed a bad protocol. But I think it is arguably a feature on the part
> of Swift for refusing to allow code to circumvent the protocol's design,
> because a protocol that is out of the end user's control is also likely a
> protocol for which the default implementations are opaque to that user and
> can't be reasoned through by that user.
>
>
> There seem to be two schools of thought in this community:  Those that
> want to empower good design, and those that want to prevent/punish bad
> design.
>
> They often look similar, but they are subtly different.  One treats the
> programmer as an intelligent adult, who may make mistakes, and would
> appreciate reminders about the possibility of problems.  The other treats
> the programmer as a child who must be protected from themselves.  I am
> strongly in the first camp.
>

I think this is quite an unfair characterization. When a programming
language can guarantee that certain things won't occur, it isn't about
punishing anyone; rather, those who have to read the code and reason about
its behavior gain tangible benefits from such constraints.


> We should provide warnings and force conflicts to be resolved in some way,
> but ultimately we need to trust the programmer to do the right thing. Also,
> as people kept saying during the 'closed by default' discussion, if they
> screw up and rename something in a confusing way, then other people will
> complain to them and they will change it.
>
>
> I'm not entirely sure on my position, though. To be convinced otherwise,
> I'd need to see a compelling real-world use case that demonstrates all of
> the following:
>
> - Safety: perhaps, with protocols, unlike class inheritance, it is almost
> always safe to make these kinds of changes unanticipated by the original
> author--it would be good to see evidence either way
>
>
> You may find this paper interesting:
> http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf
>
> It discusses traits, which are basically Swift’s protocols, plus the
> ability to handle conflicts.  It discusses at length the issues that arise
> with other systems.
>

Thanks for the link. I'll need to study this further. For the moment, one
initial thought: one key point in this paper is that conflict resolution
for traits hinges on the fact that they do not access state, and so the
diamond problem does not occur.


> This is a very common problem that only a few programming languages have
> found successful solutions to.  I would also point you to Eiffel’s model
> for multiple inheritance (select, rename, undefine, export).  I think if we
> keep working on it, we can find a uniquely swift-feeling solution which
> solves the issue :-)
>
>
> - Necessity: earlier, examples were cited where at least one of two
> conflicting protocols were under the user's control; in that case, this
> feature isn't needed, because that protocol's requirements can be trivially
> renamed
>
>
> I ran into a case of the diamond problem with protocols again today in a
> real world project.  Both classes were under my control, but I wasn’t able
> to avoid the name conflict because they had a common ancestor.
>

Can you explain this in more detail? Were you working with protocols or
classes?

If a protocol inherits from two protocols with a common ancestor, the
protocol requirements from that ancestor cannot possibly conflict with
themselves. Are you talking about default implementations? If so, there's
another thread (recent, but dormant now) suggesting new syntax to call a
named default implementation from an implementation in a conforming type
(and by extension (har har), from a default implementation in an inheriting
protocol). I believe that the suggestion had a pretty positive reception,
and unless I'm mistaken, it would address this particular issue (which I
agree is currently problematic).


> I was able to solve it by copy/pasting the winning method definition, but
> this is definitely not ideal, since I must now maintain code in two places
> which makes upkeep/changes more difficult.
>
> What I want here is the ability to notate the winner in my inheriting
> protocol.
>
>
> - Good design: show me that the design patterns enabled by the feature are
> better than what is possible with workarounds; if a renaming or hiding
> feature is expedient, but an alternative approach would promote less
> fragile or more Swifty design, then we should be exploring ways to simplify
> or promote an alternative approach; one consideration, for example, is that
> naming of anything is hard, 

Re: [swift-evolution] [Meta] Proposal status page

[Jordan Rose via swift-evolution]

> On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
> 
>> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch  wrote:
>> 
>> Is it possible to have a repo named apple.github.io, and still allow 
>> individual repos having their own pages (like 
>> apple.github.io/swift-evolution)?
> 
> The `username.github.io` and `username.github.io/projectname` combination 
> works for me.
> 
> The `orgname.github.io` and `orgname.github.io/projectname` combination 
> should also work (but I haven't tried it).
> 
> 
> 
> — Ben

Thanks for the suggestion, Ben. After a bit of discussion we’ve put in a 
redirect to github.com/apple/, which is definitely better than just 404ing.

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

Re: [swift-evolution] Renaming for Protocol Conformance

[Jonathan Hull via swift-evolution]

> I argue the same thing applies here. Currently, protocols constrain the API 
> of conforming types. If a designer has reasoned through their design 
> correctly, then all is well. If a designer has made bad design choices, then 
> conforming types are constrained to have bad API design. Is that a bug or a 
> feature? It is of course a bug on the part of the designer for having 
> designed a bad protocol. But I think it is arguably a feature on the part of 
> Swift for refusing to allow code to circumvent the protocol's design, because 
> a protocol that is out of the end user's control is also likely a protocol 
> for which the default implementations are opaque to that user and can't be 
> reasoned through by that user.

There seem to be two schools of thought in this community:  Those that want to 
empower good design, and those that want to prevent/punish bad design.

They often look similar, but they are subtly different.  One treats the 
programmer as an intelligent adult, who may make mistakes, and would appreciate 
reminders about the possibility of problems.  The other treats the programmer 
as a child who must be protected from themselves.  I am strongly in the first 
camp.  We should provide warnings and force conflicts to be resolved in some 
way, but ultimately we need to trust the programmer to do the right thing. 
Also, as people kept saying during the 'closed by default' discussion, if they 
screw up and rename something in a confusing way, then other people will 
complain to them and they will change it.


> I'm not entirely sure on my position, though. To be convinced otherwise, I'd 
> need to see a compelling real-world use case that demonstrates all of the 
> following:
> 
> - Safety: perhaps, with protocols, unlike class inheritance, it is almost 
> always safe to make these kinds of changes unanticipated by the original 
> author--it would be good to see evidence either way

You may find this paper interesting:
http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf 


It discusses traits, which are basically Swift’s protocols, plus the ability to 
handle conflicts.  It discusses at length the issues that arise with other 
systems.

This is a very common problem that only a few programming languages have found 
successful solutions to.  I would also point you to Eiffel’s model for multiple 
inheritance (select, rename, undefine, export).  I think if we keep working on 
it, we can find a uniquely swift-feeling solution which solves the issue :-)


> - Necessity: earlier, examples were cited where at least one of two 
> conflicting protocols were under the user's control; in that case, this 
> feature isn't needed, because that protocol's requirements can be trivially 
> renamed

I ran into a case of the diamond problem with protocols again today in a real 
world project.  Both classes were under my control, but I wasn’t able to avoid 
the name conflict because they had a common ancestor.  I was able to solve it 
by copy/pasting the winning method definition, but this is definitely not 
ideal, since I must now maintain code in two places which makes upkeep/changes 
more difficult.

What I want here is the ability to notate the winner in my inheriting protocol.


> - Good design: show me that the design patterns enabled by the feature are 
> better than what is possible with workarounds; if a renaming or hiding 
> feature is expedient, but an alternative approach would promote less fragile 
> or more Swifty design, then we should be exploring ways to simplify or 
> promote an alternative approach; one consideration, for example, is that 
> naming of anything is hard, and the current fact that protocols *need* to 
> have well-chosen member names encourages designers to think hard--but if 
> renaming becomes possible, could we simply be enabling less thoughtful 
> protocol design with little benefit (to evaluate this, we would need some 
> sense of the answer to the necessity question above)?

Your suggestion that the framework designers should have to go back and 
refactor their code because of another framework is an indication of coupled 
design and bad code smell.  Suddenly my protocols have to know about all of the 
other protocols being used (or which could theoretically be used) and I have to 
design around them.  This is problematic.  Ideally, I should be able to design 
each protocol in a way which makes the most sense semantically for the use of 
that protocol.  Any contortions I have to make to the design away from the 
ideal are something to be avoided where possible.  I know we are used to making 
these contortions, but is it really the best design (or is it a form of 
Stockholm syndrome)?

Here is an article on Eiffel’s multiple inheritance system which makes the 
point well:
https://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html 

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Charles Srstka via swift-evolution]

> On Sep 6, 2016, at 7:11 PM, Douglas Gregor  wrote:
> 
> I *think* Charles is saying something slightly different here, and it’s a 
> viewpoint I hadn’t considered before.
> 
> We agree that there should be some kind of diagnostic when putting an 
> optional into an Any, because it’s probably not what the user intended. And 
> we know it can happen in ways we cannot diagnose statically, so the 
> diagnostic won’t be perfect. I think Charles is saying that, when this 
> happens, we don’t *want* our Objective-C code to be able to query the value 
> in that optional: in other words, it’s effectively a programmer error to 
> treat such objects as anything more than completely-opaque objects that get 
> passed around any perhaps dealt with properly in Swift code itself.

I’d say my position has three planks on it, and the above is pretty much the 
first plank: 1) the idea of an array of optionals is a concept that doesn’t 
really exist in Objective-C, and I do think that passing one to Obj-C ought to 
be considered a programmer error.

The other two planks would be:

2) Bridging arrays of optionals in this manner could mask the aforementioned 
programmer error, resulting in unexpected, hard-to-reproduce crashes when an 
NSNull is accessed as if it were something else, and:

3) Objective-C APIs that accept NSNull objects are fairly rare, so the proposed 
bridging doesn’t really solve a significant problem (and in the cases where it 
does, using a map to replace nils with NSNulls is not difficult to write).

Charles

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

Re: [swift-evolution] #pragma

[Xiaodi Wu via swift-evolution]

I'm not sure I understand. Swift comments are parsed. Are you saying that
this is a problem? If so, why do you think it's a problem?


On Tue, Sep 6, 2016 at 7:19 PM, isidoro carlo ghezzi <
isidoro.ghe...@icloud.com> wrote:

> Just another consideration: the consequence could be about avoiding any
> `#pragma` (or equivalent), semantic instructions out of comments, those, in
> my opinion, should be fully ignored by compiler and IDE: knowing that
> comments are not ignored  by compiler or IDE, a developer may think not
> using comments his code at all.
> `// isghe: maybe some hack code here it will be executed by IDE.`
> That is why I am proposing a `#pragma` or equivalent.
> thanks, Isidoro
>
> On Sep 06, 2016, at 02:10 AM, isidoro carlo ghezzi <
> isidoro.ghe...@icloud.com> wrote:
>
> // isghe: ok
>
> Sent from my iPhone
>
> On 05 Sep 2016, at 22:31, Xiaodi Wu  wrote:
>
> I agree: "mark" (IMO) is in the same category as "todo" and "fixme", and
> all are bona fide comments. If you wish your code to be disabled without
> becoming parsed as a comment, use instead `#if false`.
>
> On Mon, Sep 5, 2016 at 15:27 Jean-Daniel Dupas via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > Le 5 sept. 2016 à 00:53, isidoro carlo ghezzi via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >
>> > Hi all,
>> >
>> > I think the "old style" `#pragma` is necessary in Swift.
>> > Exactly in the same way it is available in C/C++ or Objective-C/C++, or
>> in something else portable way.
>> >
>> > Because `#pragma` is not handled in Swift, in Xcode they overloaded the
>> semantic of comments, giving to the comment `// MARK:` the semantic of
>> `#pragma mark`
>> >
>> > But my point of view is that, I would like that what it is written in a
>> source comment (what it is written after a // or between /* */ ) should be
>> fully ignore by compiler or IDE.
>> >
>> > I understand that maybe a compiler shouldn't lose time handling
>> `#pragma options`, but giving semantics to source comment, I think it can
>> be dangerous and misunderstood.
>> >
>> > The implementation in Swift compiler should be simple, ignoring any
>> line beginning with `#pragma` (ok I know It is not simple)
>> > The IDE will handle the `#pragma`
>> >
>> > That's why they invented `#pragma`in C/C++ Objective-C/C++ right?
>>
>> I don’t think it is a reason pragma exists. except for #pragma mark, I’m
>> not sure the compiler ignore any pragma. They are used to control the
>> compiler behaviors (controlling warning, specifying linker dependencies,
>> enabled specific feature like OpenMP, etc…) and not at all to interact with
>> the IDE. I would even says that pragma mark is an abuse of the #pragma
>> construct as it is ignored by the compiler and used by the IDE only.
>>
>> I’m strongly again introducing #pragma without very very good reason into
>> swift. Asking the IDE to parse comment to extract metadata is not worst
>> abusing pragma to do the same, and at least it is forward and backward
>> compatible with any other tools.
>>
>> ___
>> 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] Further directions for id-as-Any

[Joe Groff via swift-evolution]

> On Sep 6, 2016, at 5:19 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> In the current Swift 3 betas, value types can now be passed into Objective-C 
> as opaque box objects. A couple of reviews are currently running which tweak 
> this bridging, exposing Optionals and NSValue/NSNumber-compatible types in 
> more natural ways. These are all Good Things. I'd like to look ahead and 
> sketch out a way this feature could evolve further. This will not be 
> detailed, and much or all of it may be out of scope for Phase 1.
> 
> 
> Firstly, I think we could make boxed value types much more usable from 
> Objective-C:
> 
> 1. We could bridge selector calls to equivalent Swift methods, where those 
> methods are Objective-C-compatible (other than being on a value type). This 
> could actually be done dynamically if enough metadata is available.
> 
> 2. We could generate a separate subclass of our box class for each bridged 
> Swift type. This could actually *still* be done dynamically, I believe.
> 
> 3. We could permit value types to conform to @objc protocols. This would open 
> up several nice features to us; perhaps most importantly, a value type could 
> conform to NSCoding and thereby participate in Foundation's serialization 
> mechanisms. I suspect that at this point, the box subclasses would have to 
> become "real", i.e., registered at load time. (Perhaps they're only greedily 
> registered if they have an explicit @objc?)
> 
> 4. We could explicitly declare the bridged methods, properties, and 
> conformances in the generated -Swift.h file, thereby making Swift value types 
> directly available to Objective-C, where they can be allocated, accessed, and 
> manipulated in boxed form.
> 
> 
> Secondly—and separately, but relatedly—I believe a few simple changes could 
> liberalize the @objc-compatibility rules, permitting many more members to be 
> exposed to Objective-C:
> 
> 1. We could run "omit needless words" in reverse when exposing Swift methods 
> to Objective-C. This would prevent overloads from clashing in Objective-C, 
> and would also have the bonus feature of producing more idiomatic Objective-C 
> interfaces. (Incidentally, is a change considered source-breaking if it 
> breaks Objective-C code, not Swift code?)
> 
> 2. We could grant access to members using Swift-only type features by 
> allowing the Objective-C versions to have looser types than the Swift 
> versions, and dynamically enforcing the missing constraints instead. For 
> instance, a member with a complicated `where` clause might omit the clause in 
> its Objective-C declaration, but enforce it with a dynamic test.
> 
> 3. I suspect it might be possible to expose generic types to Objective-C with 
> some custom class methods. For instance, a Swift type with `Key` and `Value` 
> type parameters might have `+classWithKey:(Class)keyClass 
> value:(Class)valueClass` and +`allocWithKey:(Class)keyClass 
> value:(Class)valueClass` methods on it.
> 
> 
> Are these potential features of interest? If so, to what extent do they 
> affect binary compatibility? On the one hand, they are extensions, adding 
> transparency to things which are currently opaque. But on the other hand, 
> they will presumably involve generating type metadata.

Yeah, this is definitely a direction that at least I am interested in. Letting 
value types conform to @objc protocols and have @objc methods would be 
especially empowering for Cocoa APIs. There are some subtleties—many ObjC 
protocols are *intended* to be class-constrained, particularly delegate 
protocols, and these protocols also tend to be used as weak references and 
other concepts that only really make sense for classes. Your point (4) also 
raises a question of whether Swift value types ought to be exposed to ObjC in 
their boxed or unboxed forms; it seems to me that there are many structs that 
you'd want to export back to C or ObjC as plain structs and not boxed objects. 
We're also still researching the backward compatibility ramifications of 
changing the bridging model. While at face value, these ought to be additive 
changes, since we're turning purportedly opaque ObjC objects into meaningful 
ones, and relaxing generic constraints, the fact of the matter is people can 
and do rely on implementation details that are supposed to be private and 
subject to change. I'm hopeful we can explore this model going forward, though.

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

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Sep 6, 2016, at 5:21 PM, Joe Groff  wrote:
> 
> 
>>> On Sep 6, 2016, at 5:11 PM, Douglas Gregor  wrote:
>>> 
>>> 
>>> On Sep 6, 2016, at 4:50 PM, Joe Groff  wrote:
>>> 
>>> 
> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction 
> of Swift. When writing your review, here are some questions you might 
> want to answer in your review:
> 
>• What is your evaluation of the proposal?
 Strong -1 as is.
 
>• Is the problem being addressed significant enough to warrant a 
> change to Swift?
 Not only do I not believe the problem is significant, but I believe that 
 the proposal *introduces* a new problem which *is* significant, which is 
 the accidental passage of optional arrays to Objective-C. With the 
 existing behavior, such mistakes are immediately obvious as Objective-C 
 receives an opaque object that it cannot use (and probably soon crashes), 
 so they are unlikely to make it past QA testing. For many other cases, 
 particularly when nil is encountered in an array only rarely, this is 
 likely to cause strange and hard-to-debug problems at runtime when NSNull 
 pops up where code wasn’t expecting it (which I would expect to be most 
 Objective-C code), and it might not be detected until after the product 
 ships. In this way, this proposal creates a problem very similar to the 
 problem that Swift was trying to solve with optionals in the first place.
>>> 
>>> This is a fundamental problem with `Any` in Swift and `id` in Objective-C. 
>>> There's no way to statically prevent misuse of such APIs. We can, and IMO 
>>> should, provide warnings when Optionals are used in unconstrained contexts 
>>> without either being unwrapped or explicitly annotated somehow. That 
>>> doesn't conflict with this proposal, though.
>> 
>> I *think* Charles is saying something slightly different here, and it’s a 
>> viewpoint I hadn’t considered before.
>> 
>> We agree that there should be some kind of diagnostic when putting an 
>> optional into an Any, because it’s probably not what the user intended. And 
>> we know it can happen in ways we cannot diagnose statically, so the 
>> diagnostic won’t be perfect. I think Charles is saying that, when this 
>> happens, we don’t *want* our Objective-C code to be able to query the value 
>> in that optional: in other words, it’s effectively a programmer error to 
>> treat such objects as anything more than completely-opaque objects that get 
>> passed around any perhaps dealt with properly in Swift code itself.
> 
> I'm not sure I agree with this sentiment. It feels contrary to what you get 
> when you put an Optional in an Any in Swift, since we consider Optional to 
> dynamically be a supertype of its payload:
> 
>let x1: Int? = 1
>let x2: Any = x1
>print(x2 as! Int) // prints 1

I wasn't expressing an opinion per se; just trying to clear up a perceived 
misunderstanding. 

  - Doug, pretending to be a neutral review manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Joe Groff via swift-evolution]

> On Sep 6, 2016, at 5:11 PM, Douglas Gregor  wrote:
> 
>> 
>> On Sep 6, 2016, at 4:50 PM, Joe Groff  wrote:
>> 
>> 
>>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution 
>>>  wrote:
>>> 
 On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
• What is your evaluation of the proposal?
>>> Strong -1 as is.
>>> 
• Is the problem being addressed significant enough to warrant a change 
 to Swift?
>>> Not only do I not believe the problem is significant, but I believe that 
>>> the proposal *introduces* a new problem which *is* significant, which is 
>>> the accidental passage of optional arrays to Objective-C. With the existing 
>>> behavior, such mistakes are immediately obvious as Objective-C receives an 
>>> opaque object that it cannot use (and probably soon crashes), so they are 
>>> unlikely to make it past QA testing. For many other cases, particularly 
>>> when nil is encountered in an array only rarely, this is likely to cause 
>>> strange and hard-to-debug problems at runtime when NSNull pops up where 
>>> code wasn’t expecting it (which I would expect to be most Objective-C 
>>> code), and it might not be detected until after the product ships. In this 
>>> way, this proposal creates a problem very similar to the problem that Swift 
>>> was trying to solve with optionals in the first place.
>> 
>> This is a fundamental problem with `Any` in Swift and `id` in Objective-C. 
>> There's no way to statically prevent misuse of such APIs. We can, and IMO 
>> should, provide warnings when Optionals are used in unconstrained contexts 
>> without either being unwrapped or explicitly annotated somehow. That doesn't 
>> conflict with this proposal, though.
> 
> I *think* Charles is saying something slightly different here, and it’s a 
> viewpoint I hadn’t considered before.
> 
> We agree that there should be some kind of diagnostic when putting an 
> optional into an Any, because it’s probably not what the user intended. And 
> we know it can happen in ways we cannot diagnose statically, so the 
> diagnostic won’t be perfect. I think Charles is saying that, when this 
> happens, we don’t *want* our Objective-C code to be able to query the value 
> in that optional: in other words, it’s effectively a programmer error to 
> treat such objects as anything more than completely-opaque objects that get 
> passed around any perhaps dealt with properly in Swift code itself.

I'm not sure I agree with this sentiment. It feels contrary to what you get 
when you put an Optional in an Any in Swift, since we consider Optional to 
dynamically be a supertype of its payload:

let x1: Int? = 1
let x2: Any = x1
print(x2 as! Int) // prints 1

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

Re: [swift-evolution] #pragma

[isidoro carlo ghezzi via swift-evolution]

Just another consideration: the consequence could be about avoiding any 
`#pragma` (or equivalent), semantic instructions out of comments, those, in my 
opinion, should be fully ignored by compiler and IDE: knowing that comments are 
not ignored  by compiler or IDE, a developer may think not using comments his 
code at all.
`// isghe: maybe some hack code here it will be executed by IDE.`
That is why I am proposing a `#pragma` or equivalent.
thanks, Isidoro

On Sep 06, 2016, at 02:10 AM, isidoro carlo ghezzi  
wrote:

// isghe: ok

Sent from my iPhone

On 05 Sep 2016, at 22:31, Xiaodi Wu  wrote:

I agree: "mark" (IMO) is in the same category as "todo" and "fixme", and all 
are bona fide comments. If you wish your code to be disabled without becoming parsed as a comment, use 
instead `#if false`.

On Mon, Sep 5, 2016 at 15:27 Jean-Daniel Dupas via swift-evolution 
 wrote:


Le 5 sept. 2016 à 00:53, isidoro carlo ghezzi via swift-evolution 
 a écrit :

Hi all,

I think the "old style" `#pragma` is necessary in Swift.
Exactly in the same way it is available in C/C++ or Objective-C/C++, or in 
something else portable way.

Because `#pragma` is not handled in Swift, in Xcode they overloaded the 
semantic of comments, giving to the comment `// MARK:` the semantic of `#pragma 
mark`

But my point of view is that, I would like that what it is written in a source 
comment (what it is written after a // or between /* */ ) should be fully 
ignore by compiler or IDE.

I understand that maybe a compiler shouldn't lose time handling `#pragma 
options`, but giving semantics to source comment, I think it can be dangerous 
and misunderstood.

The implementation in Swift compiler should be simple, ignoring any line 
beginning with `#pragma` (ok I know It is not simple)
The IDE will handle the `#pragma`

That's why they invented `#pragma`in C/C++ Objective-C/C++ right?


I don’t think it is a reason pragma exists. except for #pragma mark, I’m not 
sure the compiler ignore any pragma. They are used to control the compiler 
behaviors (controlling warning, specifying linker dependencies, enabled 
specific feature like OpenMP, etc…) and not at all to interact with the IDE. I 
would even says that pragma mark is an abuse of the #pragma construct as it is 
ignored by the compiler and used by the IDE only.

I’m strongly again introducing #pragma without very very good reason into 
swift. Asking the IDE to parse comment to extract metadata is not worst abusing 
pragma to do the same, and at least it is forward and backward compatible with 
any other tools.

___
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] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Douglas Gregor via swift-evolution]

> On Sep 6, 2016, at 4:50 PM, Joe Groff  wrote:
> 
> 
>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> • What is your evaluation of the proposal?
>> Strong -1 as is.
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> Not only do I not believe the problem is significant, but I believe that the 
>> proposal *introduces* a new problem which *is* significant, which is the 
>> accidental passage of optional arrays to Objective-C. With the existing 
>> behavior, such mistakes are immediately obvious as Objective-C receives an 
>> opaque object that it cannot use (and probably soon crashes), so they are 
>> unlikely to make it past QA testing. For many other cases, particularly when 
>> nil is encountered in an array only rarely, this is likely to cause strange 
>> and hard-to-debug problems at runtime when NSNull pops up where code wasn’t 
>> expecting it (which I would expect to be most Objective-C code), and it 
>> might not be detected until after the product ships. In this way, this 
>> proposal creates a problem very similar to the problem that Swift was trying 
>> to solve with optionals in the first place.
> 
> This is a fundamental problem with `Any` in Swift and `id` in Objective-C. 
> There's no way to statically prevent misuse of such APIs. We can, and IMO 
> should, provide warnings when Optionals are used in unconstrained contexts 
> without either being unwrapped or explicitly annotated somehow. That doesn't 
> conflict with this proposal, though.

I *think* Charles is saying something slightly different here, and it’s a 
viewpoint I hadn’t considered before.

We agree that there should be some kind of diagnostic when putting an optional 
into an Any, because it’s probably not what the user intended. And we know it 
can happen in ways we cannot diagnose statically, so the diagnostic won’t be 
perfect. I think Charles is saying that, when this happens, we don’t *want* our 
Objective-C code to be able to query the value in that optional: in other 
words, it’s effectively a programmer error to treat such objects as anything 
more than completely-opaque objects that get passed around any perhaps dealt 
with properly in Swift code itself.

- Doug


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

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Chris Lattner via swift-evolution]

> On Sep 6, 2016, at 3:16 PM, Goffredo Marocchi  wrote:
> 
> Hello Chris,
> 
> What would you suggest for people that want to use Swift, but cannot set a 
> target of iOS 10+? Could the compiler/backward compatibility library 
> intercept those calls in older OS's and replace them with simple NSLog's with 
> some data added to the logged string?

I’m not an expert on the os logging features, and haven’t followed the issues 
involved, sorry.

-Chris

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

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Joe Groff via swift-evolution]

> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
> Strong -1 as is.
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> Not only do I not believe the problem is significant, but I believe that the 
> proposal *introduces* a new problem which *is* significant, which is the 
> accidental passage of optional arrays to Objective-C. With the existing 
> behavior, such mistakes are immediately obvious as Objective-C receives an 
> opaque object that it cannot use (and probably soon crashes), so they are 
> unlikely to make it past QA testing. For many other cases, particularly when 
> nil is encountered in an array only rarely, this is likely to cause strange 
> and hard-to-debug problems at runtime when NSNull pops up where code wasn’t 
> expecting it (which I would expect to be most Objective-C code), and it might 
> not be detected until after the product ships. In this way, this proposal 
> creates a problem very similar to the problem that Swift was trying to solve 
> with optionals in the first place.

This is a fundamental problem with `Any` in Swift and `id` in Objective-C. 
There's no way to statically prevent misuse of such APIs. We can, and IMO 
should, provide warnings when Optionals are used in unconstrained contexts 
without either being unwrapped or explicitly annotated somehow. That doesn't 
conflict with this proposal, though.

-Joe

> Gwynne brings up the interesting idea of being able to declare Objective-C 
> array parameters as NSArray. If this were allowed, and the 
> proposed bridging behavior were *only* invoked for an array so declared, I 
> might soften on this proposal, but as is, I feel that it would be a very 
> large mistake.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> A major feature of Swift was the concept of optionals, intended to prevent 
> bugs caused by nil pointers showing up where they were not expected. This 
> proposal flies directly in the face of that, and threatens to make it much 
> easier to create bugs caused by NSNull objects showing up where they are not 
> expected. In this way, I feel that it is an almost 180° contradiction of 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?
> 
> The only Objective-C bridges I have used in other languages have been in 
> AppleScript and JXA, neither of which I would expect Swift to use as a model.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Read the original discussion, read the proposal, read the comments so far.
> 
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Joe Groff via swift-evolution]

> On Sep 2, 2016, at 4:58 PM, Gwynne Raskind via swift-evolution 
>  wrote:
> 
>> On Sep 2, 2016, at 17:50, Douglas Gregor  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0140 "Bridge Optional As Its Payload Or NSNull" begins now 
>> and runs through September 8, 2016. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md
>>  • What is your evaluation of the proposal?
> 
> It seems like this would improve the utility of bridging collection types 
> (and plist types in general), and I like that it does something more sensible 
> than before with the disparate bridging behavior of Optional<>. But I do have 
> a couple of questions:
> 
> Will specifying a nullable type parameter to collections now become legal in 
> Objective-C? E.g.:
> - (void)takeOptionalCollection:(NSArray * _Nullable)collection; 
> // Bridge to [Any?]?
> 
> If not, is there any way to annotate “I want to be able to use (or not use) 
> NSNull in this collection”? If there is, does doing so affect any behaviors 
> on the Objective-C side? If there isn’t, wouldn’t it make more sense to treat 
> passing an optional to Any as requiring forced unwrapping (including the 
> implied runtime crash behavior), as is the case with other uses of optionals 
> now? I can’t think offhand of any use case where I would want an object, even 
> in pure Swift, where I didn’t know whether it was an optional or not, outside 
> of debugging.
> 
> Depending on the answers to these questions, I’m tentatively in favor of this 
> proposal.

Changing Objective-C is outside of my power. I don't think that giving 
`_Nullable` a very different meaning is a good idea, though. A feature that 
feels more in the spirit of Objective-C would be support for class sum types, 
so you could say that you had an NSArray. (Similarly, you 
could have a `typedef (NSString*|NSArray*|NSDictionary*|NSNumber*|NSNull*) 
NSPropertyList;` to obviate the need for `id` for representing property list 
types.)

-Joe

> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Honestly, I don’t feel like it is, but my opinion may not be all that valid, 
> since I’ve spent a great deal more time in pure Swift (and interop with pure 
> C) than in interop with Objective-C.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, *IF* the semantics of Optional remain consistent, which I’m not yet 
> entirely clear on.
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I haven’t worked with ObjC bridges in other languages.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> A quick reading. I was not part of any previous discussion on this topic.
> 
> 
> -- Gwynne Raskind
> More magic than a mere signature can contain
> ___
> 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] The great renaming and the state of new Unified Logging in Swift

[Chris Lattner via swift-evolution]

> On Sep 5, 2016, at 6:44 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> I hope you will not find it too impolite, but this feels like a more 
>> dogmatic decision than I would like. I agree that macro's do not feel pure, 
>> but they allow you to adapt to some of the ugliness of real world use cases 
>> (the fact that Swift forces people to write a lot of boilerplate or to give 
>> up on this pushes people that support iOS9 and want to go full Swift to drop 
>> the idea of using os_log... do we rather have that than compromise slightly 
>> on purity perhaps?). Sorry for the long aside, but maybe shedding all the C 
>> part of Objective-C did hurt a bit the ease of adaptation. 
> 
> I think you may be misinterpreting the reason macros are being deferred. As I 
> understand it, it's not because of dislike for macros, but because of a 
> desire to do them deeply and comprehensively—something more like Lisp's 
> treatment of macros than C's. It's the same reason we haven't yet done 
> regular expressions, or concurrency, or any of a hundred other features that 
> are easy to do poorly and difficult to do well.
> 
> A secondary reason is that we want time to develop easier-to-use features for 
> common boilerplate cases before we design a boilerplate feature that can do 
> anything, but is difficult to use. For instance, the use cases for the 
> proposed property behavior feature could probably be handled with macros, but 
> it would be much more difficult to define a macro than it would be to define 
> a property behavior.

Right on both points!

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

Re: [swift-evolution] [Idea] Further directions for id-as-Any

[Brent Royal-Gordon via swift-evolution]

> On Sep 6, 2016, at 10:02 AM, Will Field-Thompson  wrote:
> 
> I would rather see a Swift-centric rethinking of serialization than having 
> the runtime dynamically register Objective-C classes anytime I want to 
> serialize something. Plus, that seems like it's leaving Linux users out in 
> the cold for serialization — although I'm primarily a macOS/iOS user, so 
> maybe there's something I don't know about the corelibs Foundation 
> implementation.

I do hope that it will *also* become possible to access a Swift type in pure 
Swift given a name and a protocol it conforms to, which would allow Corelibs 
Foundation to also support NSCoding on value types. But that's a separate issue 
from improving Objective-C bridging.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

[Andrew Trick via swift-evolution]

> On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution 
>  wrote:
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is 
> unsafe about getting the byte-representation of a value?
> 
> As I understand it, “Raw” is what we use for “untyped”, so might I suggest 
> “RawBytes"?

It’s annoying, but a strict requirement in Swift that any “unsafe” operation be 
marked with the word “Unsafe” either at that point or in some enclosing scope. 
Unsafe broadly refers to various forms of memory unsafety. Unsafe bytes is 
actually safe with respect to pointer aliasing but it is unsafe because

1. It points into memory that it does not own. The developer must do something 
to to manage the memory’s lifetime.

2. It does not perform bounds-checking in release mode.

In both those respects, it’s just like UnsafeBufferPointer.

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

Re: [swift-evolution] pattern matching on variable-sized data type

[Mark Lacey via swift-evolution]

> On Sep 6, 2016, at 7:47 AM, Jean-Denis Muys via swift-evolution 
>  wrote:
> 
> Hello,
> 
> I would like to suggest an additive evolution to Swift that might be in scope 
> of phase 1 of Swift 4 (because it might have an impact on the ABI).

How would you expect this to have an impact on ABI?

Mark

> 
> The idea is to extend the pattern matching abilities of Swift to enable a 
> recursive programming style that’s very common in languages such as Lisp, ML, 
> or Prolog on a collection that is processed as a list. By analogy to ML, 
> Swift could do that on tuples, or on arrays, or on any similar, perhaps new, 
> data type. This would allow the following for example:
> 
> func listOfDifferenceOfListElements (list: List) -> Int {
> 
> switch list {
> case 〘〙: {
> return 〘〙
> }
> case 〘 let a 〙: {
> return 〘 a 〙
> }
> case 〘 let a, let b ⫸ let tail 〙: {
> return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
> }
> }
> }
> 
> 
> Where I deliberately used unusual Unicode characters to denote syntax that 
> would need to be invented:
> 
> - 〘〙 to denote the list-like data structure. It would be old style 
> parenthesis if we wanted that to be Swift’s tuple, or the usual bracket if it 
> was arrays
> - ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
> all elements following whatever has been pattern-matched so far
> - ⋙ to denote a list append operator.
> 
> If we wanted the list data-type to be tuples, this would require the ability 
> to build longer tuples from existing ones, i.e. build (a, b, c) from a and 
> (b, c), or from (a) and (b, c) (appending tuples). Array seems more suitable, 
> however.
> 
> So this post is to assess the interest in such a feature. Also note that 
> while I have tried to have an occasional look at this mailing list in the 
> past, due to its overwhelming volume, I may very well have missed a similar 
> discussion in the past. In that case, I would appreciate a pointer.
> 
> As someone who developed Lisp and Prolog software professionally in a rather 
> distant past, with an ever renewed sense of wonder, I would very much love to 
> be able to use that programming style again when it makes sense.
> 
> If there is interest, I would be willing to write up an evolution proposal.
> 
> Jean-Denis Muys
> 
> ___
> 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

[Jordan Rose via swift-evolution]

> On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev  
> wrote:
> 
> 
>> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch > > wrote:
>> 
>> Here are a few thoughts:
>> -swift=4
>> -swift-version=4
> 
> -swift-version seems like the best option to me, but Jordan will have a 
> strong opinion.  I think he’s crazy busy with Swift 3 work until late next 
> week.

:-) I missed this thread. -swift-version is all right. It doesn’t immediately 
sound nice (a bit wordy) but I don’t have anything better.

If I’m really getting nitpicky, I might note that we don’t really use = options 
in swiftc as much as separated operations (-swift-version 4).

Jordan

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

Re: [swift-evolution] SPM support for branches and commits

[The CB4 via swift-evolution]

+1
My first time saying anything on the distribution.

Working on Swift 3 migration, a lot of github projects have an non-versioned 
swift3 branch.  I've had to fork projects and create my own version tags... A 
lot of unnecessary work.

Cheers,
CB

> On Sep 6, 2016, at 12:06, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> (+swift-build-dev, which is more focused for SwiftPM work)
> 
> Hi Said,
> 
> I agree, this is something we need.
> 
> One of the things that a complete proposal for adding this needs is a precise 
> definition for the workflow and exploration about the impact on other 
> features. Some of my questions are:
> 
> 1. When will those commits be resolved and packages updated? For example, we 
> might find it useful for `swift build` to automatically fetch packages and 
> prompt when new versions are available when using tagged dependencies -- is 
> that behavior appropriate when tracking a branch?
> 
> 2. How do we manage the presence of these attributes w.r.t. producing 
> reliable package graphs. For example, should this be allowed in all 
> circumstances, or should it only be allowed when accessing a package via an 
> "untagged" path? If I depend on B, and B updates and pushes a tag to start 
> referencing a branch, do I see an error, or a warning, to let me know my 
> product is no longer being built from tagged repositories?
> 
> 3. We anticipate needing an explicit workflow for development against an 
> untagged group of packages (we've been colloquially calling this 
> "master"-style development). If we had that feature, which let you just use a 
> bunch of packages in whatever state they were in on the local filesystem, 
> would that change how you felt about wanting this in the `Package.swift` 
> manifest?
> 
> I am in favor of getting a complete proposal for this feature on the books, 
> and agree with you that implementing it should be relatively easy. The 
> proposal doesn't have to be elaborate, but I think it does need to work 
> through some of the impact of this feature and ways we can mitigate potential 
> problems.
> 
> Cheers,
>  - Daniel
> 
>> On Sep 6, 2016, at 7:31 AM, Daniel Leping via swift-evolution 
>>  wrote:
>> 
>> +1 here. It becomes much more crucial when you work with finely grained 
>> projects with each module in its own repo. Making a new release when you 
>> push a fix becomes too much of job to do.
>> 
>> On Tue, Sep 6, 2016 at 5:08 PM, Said Sikira via swift-evolution 
>>  wrote:
>>> Yes, I agree that tags are far better option for production use, but 
>>> development process stage would certainly benefit from possibility to track 
>>> specific branch or commit. Having to rely completely on versioned tags in 
>>> development stage would not be easy nor very productive.
>>> 
>>> Said
>>> 
 On September 6, 2016 at 3:49:06 PM, Guillaume DIDIER 
 (guillaume.didier.2...@polytechnique.org) wrote:
 
 I think that the ability to fetch a branch or a commit may be interesting
 (basically anything that git understands), would be nice,
 but with the caveat that for production use it is far better to use à 
 fixed version (i.e. a tag).
 We do not want that most packages are used by specifying the master branch.
 
 
 Guillaume DIDIER 
 —
 ÉCOLE POLYTECHNIQUE
 91128 PALAISEAU CEDEX
 guillaume.did...@polytechnique.edu
 www.polytechnique.edu
 —
 
 PS : I am new here, do not hesitate to correct me.
 
> Le 6 sept. 2016 à 15:41, Said Sikira via swift-evolution 
>  a écrit :
> 
> Hi,
> 
> Our code is almost always developed and pushed in small incremental 
> changes. When we implement critical amount of changes in our code, we 
> push new version.
> 
> When adding dependencies to Package.swift file, we supply their 
> repository url and version we want to use. However, differentiating code 
> only by it’s version is not enough in some cases. When writing new code 
> features, we use branches. They enable all the mechanisms one needs to 
> create, test and deploy new features without polluting production 
> environment.
> 
> I think that Swift Package Manager should have support for branches (and 
> commits). There are several reasons why this feature would greatly 
> improve developer workflow:
> 
> Writing new features. Being able to specify branch in Package.swift would 
> make creating and testing new features easier. You wouldn’t need to push 
> new version to be able to use it in your Swift program. You would just 
> specify the branch you’re working on.
> Differentiating between new Swift versions. This problem comes from the 
> current Swift 2.2 -> Swift 3.0 migration. Many framework developers use 
> specific branches (swift–3, swift3.0) to work on migration of their API’s 

Re: [swift-evolution] [Idea] Further directions for id-as-Any

[Will Field-Thompson via swift-evolution]

This might be useful for some cases, but I have some concerns about tying
serialization to this. I would rather see a Swift-centric rethinking of
serialization than having the runtime dynamically register Objective-C
classes anytime I want to serialize something. Plus, that seems like it's
leaving Linux users out in the cold for serialization — although I'm
primarily a macOS/iOS user, so maybe there's something I don't know about
the corelibs Foundation implementation.

Will Field-Thompson

On Tue, Sep 6, 2016 at 8:20 AM Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> In the current Swift 3 betas, value types can now be passed into
> Objective-C as opaque box objects. A couple of reviews are currently
> running which tweak this bridging, exposing Optionals and
> NSValue/NSNumber-compatible types in more natural ways. These are all Good
> Things. I'd like to look ahead and sketch out a way this feature could
> evolve further. This will not be detailed, and much or all of it may be out
> of scope for Phase 1.
>
>
> Firstly, I think we could make boxed value types much more usable from
> Objective-C:
>
> 1. We could bridge selector calls to equivalent Swift methods, where those
> methods are Objective-C-compatible (other than being on a value type). This
> could actually be done dynamically if enough metadata is available.
>
> 2. We could generate a separate subclass of our box class for each bridged
> Swift type. This could actually *still* be done dynamically, I believe.
>
> 3. We could permit value types to conform to @objc protocols. This would
> open up several nice features to us; perhaps most importantly, a value type
> could conform to NSCoding and thereby participate in Foundation's
> serialization mechanisms. I suspect that at this point, the box subclasses
> would have to become "real", i.e., registered at load time. (Perhaps
> they're only greedily registered if they have an explicit @objc?)
>
> 4. We could explicitly declare the bridged methods, properties, and
> conformances in the generated -Swift.h file, thereby making Swift value
> types directly available to Objective-C, where they can be allocated,
> accessed, and manipulated in boxed form.
>
>
> Secondly—and separately, but relatedly—I believe a few simple changes
> could liberalize the @objc-compatibility rules, permitting many more
> members to be exposed to Objective-C:
>
> 1. We could run "omit needless words" in reverse when exposing Swift
> methods to Objective-C. This would prevent overloads from clashing in
> Objective-C, and would also have the bonus feature of producing more
> idiomatic Objective-C interfaces. (Incidentally, is a change considered
> source-breaking if it breaks Objective-C code, not Swift code?)
>
> 2. We could grant access to members using Swift-only type features by
> allowing the Objective-C versions to have looser types than the Swift
> versions, and dynamically enforcing the missing constraints instead. For
> instance, a member with a complicated `where` clause might omit the clause
> in its Objective-C declaration, but enforce it with a dynamic test.
>
> 3. I suspect it might be possible to expose generic types to Objective-C
> with some custom class methods. For instance, a Swift type with `Key` and
> `Value` type parameters might have `+classWithKey:(Class)keyClass
> value:(Class)valueClass` and +`allocWithKey:(Class)keyClass
> value:(Class)valueClass` methods on it.
>
>
> Are these potential features of interest? If so, to what extent do they
> affect binary compatibility? On the one hand, they are extensions, adding
> transparency to things which are currently opaque. But on the other hand,
> they will presumably involve generating type metadata.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] #pragma

[Marinus van der Lugt via swift-evolution]

> 
> I understand that maybe a compiler shouldn't lose time handling `#pragma 
> options`, but giving semantics to source comment, I think it can be dangerous 
> and misunderstood.

Could you elaborate what could be dangerous or misunderstood?

Rien.

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

[swift-evolution] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

Hello,

I would like to suggest an additive evolution to Swift that might be in scope 
of phase 1 of Swift 4 (because it might have an impact on the ABI).

The idea is to extend the pattern matching abilities of Swift to enable a 
recursive programming style that’s very common in languages such as Lisp, ML, 
or Prolog on a collection that is processed as a list. By analogy to ML, Swift 
could do that on tuples, or on arrays, or on any similar, perhaps new, data 
type. This would allow the following for example:

func listOfDifferenceOfListElements (list: List) -> Int {

switch list {
case 〘〙: {
return 〘〙
}
case 〘 let a 〙: {
return 〘 a 〙
}
case 〘 let a, let b ⫸ let tail 〙: {
return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
}
}
}


Where I deliberately used unusual Unicode characters to denote syntax that 
would need to be invented:

- 〘〙 to denote the list-like data structure. It would be old style parenthesis 
if we wanted that to be Swift’s tuple, or the usual bracket if it was arrays
- ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
all elements following whatever has been pattern-matched so far
- ⋙ to denote a list append operator.

If we wanted the list data-type to be tuples, this would require the ability to 
build longer tuples from existing ones, i.e. build (a, b, c) from a and (b, c), 
or from (a) and (b, c) (appending tuples). Array seems more suitable, however.

So this post is to assess the interest in such a feature. Also note that while 
I have tried to have an occasional look at this mailing list in the past, due 
to its overwhelming volume, I may very well have missed a similar discussion in 
the past. In that case, I would appreciate a pointer.

As someone who developed Lisp and Prolog software professionally in a rather 
distant past, with an ever renewed sense of wonder, I would very much love to 
be able to use that programming style again when it makes sense.

If there is interest, I would be willing to write up an evolution proposal.

Jean-Denis Muys

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

Re: [swift-evolution] pattern matching on variable-sized data type

[Anton Zhilin via swift-evolution]

You can process lists using pattern matching today:

enum List {
case Nil
indirect case Cons(T, List)
}
let list: List = .Cons(2, .Cons(3, .Nil))
switch list {
case .Nil: ...
case .Cons(let x, .Nil): ...
case .Cons(let x, .Cons(let y, .Nil)): ...
default: handleLongList(list)
}

The thing is, such lists are not idiomatic in Swift. Pattern matching on
Array also kind-of works:

let array: Array = ...
switch array.first {
case .some(let first):
processHead(first)
processTail(array.dropFirst())
case .none:
handleNil()
}

Again, it’s not the most idiomatic way to do this in Swift. Also, there is
no guaranteed tail-call optimization.

2016-09-06 17:48 GMT+03:00 Jean-Denis Muys via swift-evolution <
swift-evolution@swift.org>:

Hello,
>
> I would like to suggest an additive evolution to Swift that might be in
> scope of phase 1 of Swift 4 (because it might have an impact on the ABI).
>
> The idea is to extend the pattern matching abilities of Swift to enable a
> recursive programming style that’s very common in languages such as Lisp,
> ML, or Prolog on a collection that is processed as a list. By analogy to
> ML, Swift could do that on tuples, or on arrays, or on any similar, perhaps
> new, data type. This would allow the following for example:
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

The recursive call should obviously read

return 〘 a-b 〙 ⋙ listOfDifferenceOfListElements(tail)

Jean-Denis




> On 06 Sep 2016, at 16:48, Jean-Denis Muys  wrote:
> 
> Hello,
> 
> I would like to suggest an additive evolution to Swift that might be in scope 
> of phase 1 of Swift 4 (because it might have an impact on the ABI).
> 
> The idea is to extend the pattern matching abilities of Swift to enable a 
> recursive programming style that’s very common in languages such as Lisp, ML, 
> or Prolog on a collection that is processed as a list. By analogy to ML, 
> Swift could do that on tuples, or on arrays, or on any similar, perhaps new, 
> data type. This would allow the following for example:
> 
> func listOfDifferenceOfListElements (list: List) -> Int {
> 
> switch list {
> case 〘〙: {
> return 〘〙
> }
> case 〘 let a 〙: {
> return 〘 a 〙
> }
> case 〘 let a, let b ⫸ let tail 〙: {
> return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
> }
> }
> }
> 
> 
> Where I deliberately used unusual Unicode characters to denote syntax that 
> would need to be invented:
> 
> - 〘〙 to denote the list-like data structure. It would be old style 
> parenthesis if we wanted that to be Swift’s tuple, or the usual bracket if it 
> was arrays
> - ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
> all elements following whatever has been pattern-matched so far
> - ⋙ to denote a list append operator.
> 
> If we wanted the list data-type to be tuples, this would require the ability 
> to build longer tuples from existing ones, i.e. build (a, b, c) from a and 
> (b, c), or from (a) and (b, c) (appending tuples). Array seems more suitable, 
> however.
> 
> So this post is to assess the interest in such a feature. Also note that 
> while I have tried to have an occasional look at this mailing list in the 
> past, due to its overwhelming volume, I may very well have missed a similar 
> discussion in the past. In that case, I would appreciate a pointer.
> 
> As someone who developed Lisp and Prolog software professionally in a rather 
> distant past, with an ever renewed sense of wonder, I would very much love to 
> be able to use that programming style again when it makes sense.
> 
> If there is interest, I would be willing to write up an evolution proposal.
> 
> Jean-Denis Muys
> 

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

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Zach Waldowski via swift-evolution]

For a wrapper, are there any public hooks into dyld that allow us to do
anything meaningful with #dsoHandle on prior OS? Without that, and
without using #dsoHandle, wrapping os_log is essentially useless.

Cheers!
  Zachary Waldowski
  z...@waldowski.me


On Mon, Sep 5, 2016, at 10:59 AM, Douglas Gregor via swift-evolution wrote:
>
>
> Sent from my iPhone
>
> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi
>  wrote:
>> Hey Doug,
>>
>> How do I use it in Swift code without a wrapper, which is
>> understandably a bit pointless, if I still support iOS 9?
>
> #if or a wrapper are your best options.
>
>   - Doug
>
>>
>> Sent from my iPhone
>>
>> On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution > evolut...@swift.org> wrote:
>>> Where should the lack of {public} be reported then?
>>>
>>> This seems like it falls under jira and not radar because it's in
>>> swift open source but I'm not 100 percent
>>>
>>> Brandon
>>>
>>> Sent from my iPad
>>>
>>> On Sep 4, 2016, at 11:48 PM, Douglas Gregor 
>>> wrote:


 Sent from my iPhone

 On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution >>> evolut...@swift.org> wrote:
>
>> On 3 Sep 2016, at 19:13, Brandon Knope  wrote:
>>
>> Thank you! I was looking for this last night and failed.
>>
>> Why do you think {public} isn't included?
>
> I don't know, but trying to reimplement __builtin_os_log_format in
> the overlay seems wrong. It would be better to have a variant of
> __builtin_os_log_format which takes a va_list.


 __builtin_os_log_format is implemented by Clang, not a library, and
 is quite involved. Implementing os_log in an overlay to provide
 near feature-compatibility with the C API is the right approach for
 Swift 3, where a more comprehensive solution (say, a general
 logging API based on string interpolation or similar) is way out of
 scope.

   - Doug


>
> -- Ben
>
> ___
> 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

[swift-evolution] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

Hello,

I would like to suggest an additive evolution to Swift that might be in scope 
of phase 1 of Swift 4 (because it might have an impact on the ABI).

The idea is to extend the pattern matching abilities of Swift to enable a 
recursive programming style that’s very common in languages such as Lisp, ML, 
or Prolog on a collection that is processed as a list. By analogy to ML, Swift 
could do that on tuples, or on arrays, or on any similar, perhaps new, data 
type. This would allow the following for example:

func listOfDifferenceOfListElements (list: List) -> Int {

switch list {
case 〘〙: {
return 〘〙
}
case 〘 let a 〙: {
return 〘 a 〙
}
case 〘 let a, let b ⫸ let tail 〙: {
return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
}
}
}


Where I deliberately used unusual Unicode characters to denote syntax that 
would need to be invented:

- 〘〙 to denote the list-like data structure. It would be old style parenthesis 
if we wanted that to be Swift’s tuple, or the usual bracket if it was arrays
- ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
all elements following whatever has been pattern-matched so far
- ⋙ to denote a list append operator.

If we wanted the list data-type to be tuples, this would require the ability to 
build longer tuples from existing ones, i.e. build (a, b, c) from a and (b, c), 
or from (a) and (b, c) (appending tuples). Array seems more suitable, however.

So this post is to assess the interest in such a feature. Also note that while 
I have tried to have an occasional look at this mailing list in the past, due 
to its overwhelming volume, I may very well have missed a similar discussion in 
the past. In that case, I would appreciate a pointer.

As someone who developed Lisp and Prolog software professionally in a rather 
distant past, with an ever renewed sense of wonder, I would very much love to 
be able to use that programming style again when it makes sense.

If there is interest, I would be willing to write up an evolution proposal.

Jean-Denis Muys

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

Re: [swift-evolution] SPM support for branches and commits

[Daniel Leping via swift-evolution]

+1 here. It becomes much more crucial when you work with finely grained
projects with each module in its own repo. Making a new release when you
push a fix becomes too much of job to do.

On Tue, Sep 6, 2016 at 5:08 PM, Said Sikira via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes, I agree that tags are far better option for production use, but
> development process stage would certainly benefit from possibility to track
> specific branch or commit. Having to rely completely on versioned tags in
> development stage would not be easy nor very productive.
>
> Said
>
> On September 6, 2016 at 3:49:06 PM, Guillaume DIDIER (
> guillaume.didier.2...@polytechnique.org) wrote:
>
> I think that the ability to fetch a branch or a commit may be interesting
> (basically anything that git understands), would be nice,
> but with the caveat that for production use it is far better to use à
> fixed version (i.e. a tag).
> We do not want that most packages are used by specifying the master branch.
>
>
> *Guillaume DIDIER *
> —
> *ÉCOLE POLYTECHNIQUE*
> 91128 PALAISEAU CEDEX
> guillaume.did...@polytechnique.edu
> 
> www.polytechnique.edu
> —
>
> PS : I am new here, do not hesitate to correct me.
>
> Le 6 sept. 2016 à 15:41, Said Sikira via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hi,
>
> Our code is almost always developed and pushed in small incremental
> changes. When we implement critical amount of changes in our code, we push
> new version.
>
> When adding dependencies to Package.swift file, we supply their repository
> url and version we want to use. However, differentiating code only by it’s
> version is not enough in some cases. When writing new code features, we use
> branches. They enable all the mechanisms one needs to create, test and
> deploy new features without polluting production environment.
>
> I think that Swift Package Manager should have support for branches (and
> commits). There are several reasons why this feature would greatly improve
> developer workflow:
>
>1. Writing new features. Being able to specify branch in Package.swift
>would make creating and testing new features easier. You wouldn’t need to
>push new version to be able to use it in your Swift program. You would just
>specify the branch you’re working on.
>2. Differentiating between new Swift versions. This problem comes from
>the current Swift 2.2 -> Swift 3.0 migration. Many framework developers use
>specific branches (swift–3, swift3.0) to work on migration of their API’s
>to Swift 3. However, you can’t use them in your Swift projects because they
>don’t live in the master branch in the repository. I’m sure this will also
>happen when Swift 3 starts migration to the Swift 4, until ABI becomes
>stable.
>
> SPM should also have support for specifying commits. Specifying which
> commit you want to use in your project dependency is not always a good
> idea, but it’s necessary in some cases.
>
> This shouldn’t be very hard to implement. We would need to update
> PackageDescription and Get source from swift-package-manager repository to
> enable specifying branches or commits. Pulling the branch source would just
> be another parameter in git instruction.
>
> Example:
>
> // Specifying branch
> let package = Package(
>   name: "SomePackage",
>   dependencies: [
> .Package(url: "https://repo-source.git;, branch: "new-feature")
>   ]
> )
>
> // Specifying commits
> let package = Package(
>   name: "SomePackage",
>   dependencies: [
> .Package(url: "https://repo-source.git;, commit: 
> "c336664020v4f94ed78cbe7447a39ae5ca0b6c11")
>   ]
> )
>
> What are your thoughts on this subject?
> ___
> 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] SPM support for branches and commits

[Said Sikira via swift-evolution]

Yes, I agree that tags are far better option for production use, but
development process stage would certainly benefit from possibility to track
specific branch or commit. Having to rely completely on versioned tags in
development stage would not be easy nor very productive.

Said

On September 6, 2016 at 3:49:06 PM, Guillaume DIDIER (
guillaume.didier.2...@polytechnique.org) wrote:

I think that the ability to fetch a branch or a commit may be interesting
(basically anything that git understands), would be nice,
but with the caveat that for production use it is far better to use à fixed
version (i.e. a tag).
We do not want that most packages are used by specifying the master branch.


*Guillaume DIDIER *
—
*ÉCOLE POLYTECHNIQUE*
91128 PALAISEAU CEDEX
guillaume.did...@polytechnique.edu

www.polytechnique.edu
—

PS : I am new here, do not hesitate to correct me.

Le 6 sept. 2016 à 15:41, Said Sikira via swift-evolution <
swift-evolution@swift.org> a écrit :

Hi,

Our code is almost always developed and pushed in small incremental
changes. When we implement critical amount of changes in our code, we push
new version.

When adding dependencies to Package.swift file, we supply their repository
url and version we want to use. However, differentiating code only by it’s
version is not enough in some cases. When writing new code features, we use
branches. They enable all the mechanisms one needs to create, test and
deploy new features without polluting production environment.

I think that Swift Package Manager should have support for branches (and
commits). There are several reasons why this feature would greatly improve
developer workflow:

   1. Writing new features. Being able to specify branch in Package.swift
   would make creating and testing new features easier. You wouldn’t need to
   push new version to be able to use it in your Swift program. You would just
   specify the branch you’re working on.
   2. Differentiating between new Swift versions. This problem comes from
   the current Swift 2.2 -> Swift 3.0 migration. Many framework developers use
   specific branches (swift–3, swift3.0) to work on migration of their API’s
   to Swift 3. However, you can’t use them in your Swift projects because they
   don’t live in the master branch in the repository. I’m sure this will also
   happen when Swift 3 starts migration to the Swift 4, until ABI becomes
   stable.

SPM should also have support for specifying commits. Specifying which
commit you want to use in your project dependency is not always a good
idea, but it’s necessary in some cases.

This shouldn’t be very hard to implement. We would need to update
PackageDescription and Get source from swift-package-manager repository to
enable specifying branches or commits. Pulling the branch source would just
be another parameter in git instruction.

Example:

// Specifying branch
let package = Package(
  name: "SomePackage",
  dependencies: [
.Package(url: "https://repo-source.git;, branch: "new-feature")
  ]
)

// Specifying commits
let package = Package(
  name: "SomePackage",
  dependencies: [
.Package(url: "https://repo-source.git;, commit:
"c336664020v4f94ed78cbe7447a39ae5ca0b6c11")
  ]
)

What are your thoughts on this subject?
___
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] SPM support for branches and commits

[Guillaume DIDIER via swift-evolution]

I think that the ability to fetch a branch or a commit may be interesting
(basically anything that git understands), would be nice,
but with the caveat that for production use it is far better to use à fixed 
version (i.e. a tag).
We do not want that most packages are used by specifying the master branch.


Guillaume DIDIER 
—
ÉCOLE POLYTECHNIQUE
91128 PALAISEAU CEDEX
guillaume.did...@polytechnique.edu 

www.polytechnique.edu 
—

PS : I am new here, do not hesitate to correct me.

> Le 6 sept. 2016 à 15:41, Said Sikira via swift-evolution 
>  a écrit :
> 
> Hi,
> 
> Our code is almost always developed and pushed in small incremental changes. 
> When we implement critical amount of changes in our code, we push new version.
> 
> When adding dependencies to Package.swift file, we supply their repository 
> url and version we want to use. However, differentiating code only by it’s 
> version is not enough in some cases. When writing new code features, we use 
> branches. They enable all the mechanisms one needs to create, test and deploy 
> new features without polluting production environment.
> 
> I think that Swift Package Manager should have support for branches (and 
> commits). There are several reasons why this feature would greatly improve 
> developer workflow:
> 
> Writing new features. Being able to specify branch in Package.swift would 
> make creating and testing new features easier. You wouldn’t need to push new 
> version to be able to use it in your Swift program. You would just specify 
> the branch you’re working on.
> Differentiating between new Swift versions. This problem comes from the 
> current Swift 2.2 -> Swift 3.0 migration. Many framework developers use 
> specific branches (swift–3, swift3.0) to work on migration of their API’s to 
> Swift 3. However, you can’t use them in your Swift projects because they 
> don’t live in the master branch in the repository. I’m sure this will also 
> happen when Swift 3 starts migration to the Swift 4, until ABI becomes stable.
> SPM should also have support for specifying commits. Specifying which commit 
> you want to use in your project dependency is not always a good idea, but 
> it’s necessary in some cases.
> 
> This shouldn’t be very hard to implement. We would need to update 
> PackageDescription and Get source from swift-package-manager repository to 
> enable specifying branches or commits. Pulling the branch source would just 
> be another parameter in git instruction.
> 
> Example:
> 
> // Specifying branch
> let package = Package(
>   name: "SomePackage",
>   dependencies: [
> .Package(url: "https://repo-source.git ", 
> branch: "new-feature")
>   ]
> )
> // Specifying commits
> let package = Package(
>   name: "SomePackage",
>   dependencies: [
> .Package(url: "https://repo-source.git ", 
> commit: "c336664020v4f94ed78cbe7447a39ae5ca0b6c11")
>   ]
> )
> What are your thoughts on this subject?
> 
> ___
> 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] SPM support for branches and commits

[Said Sikira via swift-evolution]

Hi,

Our code is almost always developed and pushed in small incremental
changes. When we implement critical amount of changes in our code, we push
new version.

When adding dependencies to Package.swift file, we supply their repository
url and version we want to use. However, differentiating code only by it’s
version is not enough in some cases. When writing new code features, we use
branches. They enable all the mechanisms one needs to create, test and
deploy new features without polluting production environment.

I think that Swift Package Manager should have support for branches (and
commits). There are several reasons why this feature would greatly improve
developer workflow:

   1. Writing new features. Being able to specify branch in Package.swift
   would make creating and testing new features easier. You wouldn’t need to
   push new version to be able to use it in your Swift program. You would just
   specify the branch you’re working on.
   2. Differentiating between new Swift versions. This problem comes from
   the current Swift 2.2 -> Swift 3.0 migration. Many framework developers use
   specific branches (swift–3, swift3.0) to work on migration of their API’s
   to Swift 3. However, you can’t use them in your Swift projects because they
   don’t live in the master branch in the repository. I’m sure this will also
   happen when Swift 3 starts migration to the Swift 4, until ABI becomes
   stable.

SPM should also have support for specifying commits. Specifying which
commit you want to use in your project dependency is not always a good
idea, but it’s necessary in some cases.

This shouldn’t be very hard to implement. We would need to update
PackageDescription and Get source from swift-package-manager repository to
enable specifying branches or commits. Pulling the branch source would just
be another parameter in git instruction.

Example:

// Specifying branch
let package = Package(
  name: "SomePackage",
  dependencies: [
.Package(url: "https://repo-source.git;, branch: "new-feature")
  ]
)

// Specifying commits
let package = Package(
  name: "SomePackage",
  dependencies: [
.Package(url: "https://repo-source.git;, commit:
"c336664020v4f94ed78cbe7447a39ae5ca0b6c11")
  ]
)

What are your thoughts on this subject?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Proposal status page

[Ben Rimmington via swift-evolution]

> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch  wrote:
> 
> Is it possible to have a repo named apple.github.io, and still allow 
> individual repos having their own pages (like 
> apple.github.io/swift-evolution)?

The `username.github.io` and `username.github.io/projectname` combination works 
for me.

The `orgname.github.io` and `orgname.github.io/projectname` combination should 
also work (but I haven't tried it).



-- Ben

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

[swift-evolution] [Idea] Further directions for id-as-Any

[Brent Royal-Gordon via swift-evolution]

In the current Swift 3 betas, value types can now be passed into Objective-C as 
opaque box objects. A couple of reviews are currently running which tweak this 
bridging, exposing Optionals and NSValue/NSNumber-compatible types in more 
natural ways. These are all Good Things. I'd like to look ahead and sketch out 
a way this feature could evolve further. This will not be detailed, and much or 
all of it may be out of scope for Phase 1.


Firstly, I think we could make boxed value types much more usable from 
Objective-C:

1. We could bridge selector calls to equivalent Swift methods, where those 
methods are Objective-C-compatible (other than being on a value type). This 
could actually be done dynamically if enough metadata is available.

2. We could generate a separate subclass of our box class for each bridged 
Swift type. This could actually *still* be done dynamically, I believe.

3. We could permit value types to conform to @objc protocols. This would open 
up several nice features to us; perhaps most importantly, a value type could 
conform to NSCoding and thereby participate in Foundation's serialization 
mechanisms. I suspect that at this point, the box subclasses would have to 
become "real", i.e., registered at load time. (Perhaps they're only greedily 
registered if they have an explicit @objc?)

4. We could explicitly declare the bridged methods, properties, and 
conformances in the generated -Swift.h file, thereby making Swift value types 
directly available to Objective-C, where they can be allocated, accessed, and 
manipulated in boxed form.


Secondly—and separately, but relatedly—I believe a few simple changes could 
liberalize the @objc-compatibility rules, permitting many more members to be 
exposed to Objective-C:

1. We could run "omit needless words" in reverse when exposing Swift methods to 
Objective-C. This would prevent overloads from clashing in Objective-C, and 
would also have the bonus feature of producing more idiomatic Objective-C 
interfaces. (Incidentally, is a change considered source-breaking if it breaks 
Objective-C code, not Swift code?)

2. We could grant access to members using Swift-only type features by allowing 
the Objective-C versions to have looser types than the Swift versions, and 
dynamically enforcing the missing constraints instead. For instance, a member 
with a complicated `where` clause might omit the clause in its Objective-C 
declaration, but enforce it with a dynamic test.

3. I suspect it might be possible to expose generic types to Objective-C with 
some custom class methods. For instance, a Swift type with `Key` and `Value` 
type parameters might have `+classWithKey:(Class)keyClass 
value:(Class)valueClass` and +`allocWithKey:(Class)keyClass 
value:(Class)valueClass` methods on it.


Are these potential features of interest? If so, to what extent do they affect 
binary compatibility? On the one hand, they are extensions, adding transparency 
to things which are currently opaque. But on the other hand, they will 
presumably involve generating type metadata.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Swift 3 Ranges

[Haravikk via swift-evolution]

> On 6 Sep 2016, at 07:39, David Hart via swift-evolution 
>  wrote:
> 
> I have the impression we exchanged flexibility for correctness (the ability 
> to represent 0.. 
> Or am I missing something?
> 
> On 6 Sep 2016, at 08:15, David Hart via swift-evolution 
> > wrote:
> 
>> Hi people,
>> 
>> I’ve recently started migrating some Swift 2 projects to Swift 3. I came 
>> across the split of Range into Range and ClosedRange and I’ve really 
>> struggled with it. Specifically, in Swift 2, I had a struct with a Range 
>> property that was initialised in many places with either a closed or open 
>> range:
>> 
>> struct Day { … }
>> struct Day : Comparable { … }
>> struct Day : Strippable { … }
>> 
>> struct Info {
>> let name: String
>> let range: Range
>> }
>> 
>> Info(name: "Christmas Vacation", range: twentyfith...thirtyfirst)
>> Info(name: "Summer Vacation", range: someday..> 
>> Now, in Swift 3, it seems like we’ve lost a type to represent any range to 
>> allow an API client the flexibility to specify it as he wishes. Is there a 
>> solution to this problem through a protocol which both ranges conform to, or 
>> are we stuck with this because of the new API?
>> 
>> protocol RangeType {
>> associatedtype Bounds
>> let lowerBound: Bound { get }
>> let upperBound: Bound { get }
>> // what else? not even sure if it is possible to define such a protocol
>> }
>> 
>> David.

The problem was that to implement both generically, a closed range was just an 
open range with the upper bound increment by one step, but as you say this 
wasn't safe as Int.max etc. could not be used.

I think if you wanted to solve this you'd need to reintroduce the concept of 
incrementing by a minimum step, which was moved away from index types during 
the changes to the new indexing model for collections. You could do this 
something like so:

// Reintroduce these methods that were lost in the new indexing API
protocol ForwardStep { func successor()? -> Self }
protocol BackwardStep : ForwardStep { func predecessor()? -> Self }

// Enable conversion of ranges
extend ClosedRange where Self.Bound : ForwardStep {
func toOpenRange() -> Range? {
guard let upperBound = self.upperBound.successor() else { 
return nil }
return self.lowerBound ..< upperBound
}
}
extend Range where Self.Bound : BackwardStep {
func toClosedRange() -> ClosedRange? {
guard let upperBound = self.upperBound.predecessor() else { 
return nil }
return self.lowerBound ... upperBound
}
}
extend ClosedRange where Self.Bound : BackwardStep {
init(_ openRange:Range)? {
guard let closedRange = openRange.toClosedRange() else { return 
nil }
self = closedRange
}
}
extend Range where Self.Bound : ForwardStep {
init(_ closedRange:Range)? {
guard let openRange = closedRange.toClosedRange() else { return 
nil }
self = openRange
}
}

I've rushed this a bit so forgive any glaring errors, but this is essentially 
how I'd bolt this on right now myself. Basically it reintroduces some of the 
flexibility, but with the safety of optionals to avoid the previous problem of 
incrementing a maximum value, this shouldn't be a problem for performance since 
it's just being used for conversion.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Proposal status page

[Adrian Zubarev via swift-evolution]

It is, read here: http://webapps.stackexchange.com/a/42555



-- 
Adrian Zubarev
Sent with Airmail

Am 6. September 2016 um 08:12:36, Jacob Bandes-Storch via swift-evolution 
(swift-evolution@swift.org) schrieb:

Is it possible to have a repo named apple.github.io, and still allow individual 
repos having their own pages (like apple.github.io/swift-evolution)?

Jacob

On Mon, Sep 5, 2016 at 7:05 AM, Ben Rimmington via swift-evolution 
 wrote:

> On 21 Jul 2016, at 19:10, Jordan Rose wrote:
>
>> On Jul 18, 2016, at 16:57, Mark Lacey wrote:
>>
>>> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch wrote:
>>>
>>> This is now live:  http://apple.github.io/swift-evolution/
>>
>> Very very nice!
>>
>> I wonder if we should do something to avoid the 404 here though: 
>> http://apple.github.io
>>
>> Perhaps a redirect to https://github.com/apple/swift or maybe directly to 
>> https://github.com/apple/swift/blob/master/README.md?
>
> The Swift Open Source project isn’t the only project under github.com/apple. 
> Any landing page here would have to come from Apple PR.

You could add a simple 
 file:

        
        
        https://developer.apple.com/opensource/; />
        404 Not Found

That will redirect to the URL which also appears at the top of the 
 page.

-- Ben

___
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] The great renaming and the state of new Unified Logging in Swift

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

On 6 Sep 2016, at 02:44, Brent Royal-Gordon  wrote:

>> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> I hope you will not find it too impolite, but this feels like a more 
>> dogmatic decision than I would like. I agree that macro's do not feel pure, 
>> but they allow you to adapt to some of the ugliness of real world use cases 
>> (the fact that Swift forces people to write a lot of boilerplate or to give 
>> up on this pushes people that support iOS9 and want to go full Swift to drop 
>> the idea of using os_log... do we rather have that than compromise slightly 
>> on purity perhaps?). Sorry for the long aside, but maybe shedding all the C 
>> part of Objective-C did hurt a bit the ease of adaptation. 
> 
> I think you may be misinterpreting the reason macros are being deferred. As I 
> understand it, it's not because of dislike for macros, but because of a 
> desire to do them deeply and comprehensively—something more like Lisp's 
> treatment of macros than C's. It's the same reason we haven't yet done 
> regular expressions, or concurrency, or any of a hundred other features that 
> are easy to do poorly and difficult to do well.
> 
> A secondary reason is that we want time to develop easier-to-use features for 
> common boilerplate cases before we design a boilerplate feature that can do 
> anything, but is difficult to use. For instance, the use cases for the 
> proposed property behavior feature could probably be handled with macros, but 
> it would be much more difficult to define a macro than it would be to define 
> a property behavior.
> 

Fair enough, I can understand and appreciate the desire to do those features 
well, but there is also the desire to use such features now that keeps me still 
writing more and more Objective-C at work. iOS 6 and iOS 7 still matter too 
much to where I work for iOS 6 to be dropped and without Objective-C's ability 
to swizzle methods we would have been in trouble with several vendors pushing 
of libraries which would crash if their code ran on an iOS 6 device, but that 
is an aside.

> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 6 Sep 2016, at 02:50, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 5 Sep 2016, at 20:01, Douglas Gregor  wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi  wrote:
 
 
 Sent from my iPhone
 
> On 5 Sep 2016, at 18:59, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi  wrote:
>> 
>> Hey Doug,
>> 
>> How do I use it in Swift code without a wrapper, which is understandably 
>> a bit pointless, if I still support iOS 9?
> 
> #if or a wrapper are your best options. 
> 
 
 This is confusing to me as the WWDC talk they specifically said not to use 
 wrappers as it would pick up the wrong context
>>> 
>>> Ah, right. I forgot about that. 
>>> 
 and using the #if directive at every call site would make for a lot of 
 repeated code... hard to use.
>>> 
>>> Yes, using #if can be boilerplate-y here. 
>>> 
>> 
>> Oh well, if it cannot be helped there is an area I will have to butt heads 
>> in code reviews...
>> 
 It would be good if macro support for Swift landed in the not too distant 
 future as cases like this make its lack of sorely missed.
>>> 
>>> Macro support is not likely to be a priority for  quite a while. 
>> 
>> I hope you will not find it too impolite, but this feels like a more 
>> dogmatic decision than I would like. I agree that macro's do not feel pure, 
>> but they allow you to adapt to some of the ugliness of real world use cases 
>> (the fact that Swift forces people to write a lot of boilerplate or to give 
>> up on this pushes people that support iOS9 and want to go full Swift to drop 
>> the idea of using os_log... do we rather have that than compromise slightly 
>> on purity perhaps?). Sorry for the long aside, but maybe shedding all the C 
>> part of Objective-C did hurt a bit the ease of adaptation. 
> 
> A macro system isn't a "slight" compromise. It's a major feature whose 
> existence would forever change the way libraries are written in Swift. It's 
> not a feature to be taken lightly. The C preprocessor is the single worst 
> part of the C language from a tooling perspective, and even very 
> well-designed macro systems (e.g., Scala's macro system is fairly 
> interesting) have taken numerous iterations. 
> 

Fair enough, I was speaking by someone lucky enough to see mostly good effects 
on the user side and not the tool implementation side. Sorry if it felt a bit 
ignorantly irritating as a statement.

If the effects of a macro system are seen as so far reaching the concern of 
getting it even in the medium term is not a completely incorrect one to have 
though, right?

>> Very few people can go iOS 10+ only and I do find a lot of great value in 
>> the new logging system and Objective-C allows me to use it a lot sooner 
>> thanks to macro support.
> 
> Objective-C "sorta" lets you use the feature sooner; you can log differently 
> on iOS 9 with your own implementation of os_los, but the OS provides far 
> better logging support with a real os_log implementation.

The point is that Objective-C kind of allows me to have my cake and eat it too 
because it makes it a lot easier to have something that still allows me to work 
on iOS 6-9 and then for iOS 10+ (which means I can use it plenty and get useful 
development and debugging information internally) I can use the real os_log.

> That's the real point here, though: os_log is not a Swift feature. It's an OS 
> feature available in Swift, and it is very very rare to have an OS-level 
> feature that works on previous OS's. 

Compatibility libraries to transform the calls into fancily formatted NSLog 
statements? Would that be an option?

>   - Doug
> 
>>> 
>>>   - Doug
>>> 
 
>   - Doug
> 
>> 
>> Sent from my iPhone
>> 
>>> On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution 
>>>  wrote:
>>> 
>>> Where should the lack of {public} be reported then?
>>> 
>>> This seems like it falls under jira and not radar because it's in swift 
>>> open source but I'm not 100 percent 
>>> 
>>> Brandon 
>>> 
>>> Sent from my iPad
>>> 
 On Sep 4, 2016, at 11:48 PM, Douglas Gregor  wrote:
 
 
 
 Sent from my iPhone
 
> On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 3 Sep 2016, at 19:13, Brandon Knope  wrote:
>> 
>> Thank you! I was looking for this last night and failed. 
>> 

Re: [swift-evolution] Swift 3 Ranges

[David Hart via swift-evolution]

I have the impression we exchanged flexibility for correctness (the ability to 
represent 0.. On 6 Sep 2016, at 08:15, David Hart via swift-evolution 
>  wrote:
> 
> Hi people,
> 
> I’ve recently started migrating some Swift 2 projects to Swift 3. I came 
> across the split of Range into Range and ClosedRange and I’ve really 
> struggled with it. Specifically, in Swift 2, I had a struct with a Range 
> property that was initialised in many places with either a closed or open 
> range:
> 
> struct Day { … }
> struct Day : Comparable { … }
> struct Day : Strippable { … }
> 
> struct Info {
> let name: String
> let range: Range
> }
> 
> Info(name: "Christmas Vacation", range: twentyfith...thirtyfirst)
> Info(name: "Summer Vacation", range: someday.. 
> Now, in Swift 3, it seems like we’ve lost a type to represent any range to 
> allow an API client the flexibility to specify it as he wishes. Is there a 
> solution to this problem through a protocol which both ranges conform to, or 
> are we stuck with this because of the new API?
> 
> protocol RangeType {
> associatedtype Bounds
> let lowerBound: Bound { get }
> let upperBound: Bound { get }
> // what else? not even sure if it is possible to define such a protocol
> }
> 
> David.
> ___
> 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] Swift 3 Ranges

[David Hart via swift-evolution]

Hi people,

I’ve recently started migrating some Swift 2 projects to Swift 3. I came across 
the split of Range into Range and ClosedRange and I’ve really struggled with 
it. Specifically, in Swift 2, I had a struct with a Range property that was 
initialised in many places with either a closed or open range:

struct Day { … }
struct Day : Comparable { … }
struct Day : Strippable { … }

struct Info {
let name: String
let range: Range
}

Info(name: "Christmas Vacation", range: twentyfith...thirtyfirst)
Info(name: "Summer Vacation", range: someday..

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

Is it possible to have a repo named apple.github.io, and still allow
individual repos having their own pages (like
apple.github.io/swift-evolution)?

Jacob

On Mon, Sep 5, 2016 at 7:05 AM, Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 21 Jul 2016, at 19:10, Jordan Rose wrote:
> >
> >> On Jul 18, 2016, at 16:57, Mark Lacey wrote:
> >>
> >>> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch wrote:
> >>>
> >>> This is now live:  http://apple.github.io/swift-evolution/
> >>
> >> Very very nice!
> >>
> >> I wonder if we should do something to avoid the 404 here though:
> http://apple.github.io
> >>
> >> Perhaps a redirect to https://github.com/apple/swift or maybe directly
> to https://github.com/apple/swift/blob/master/README.md?
> >
> > The Swift Open Source project isn’t the only project under
> github.com/apple. Any landing page here would have to come from Apple PR.
>
> You could add a simple  apple.github.io/blob/master/404.html> file:
>
> 
> 
> https://developer.apple.com/opensource/; />
> 404 Not Found
>
> That will redirect to the URL which also appears at the top of the <
> https://github.com/apple/> page.
>
> -- Ben
>
> ___
> 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