Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Taras Zakharko via swift-evolution]

How would this work with OptionSetType? It also uses leading dot prefixes for 
initialisers, but implementations are usually structs. If I understand 
correctly, leading dot can be used in any case where the type can be inferred 
by the compiler. Changing the rules for enums seems strange to me. 

Best, 

 Taras


> On 01 Apr 2016, at 05:41, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance 
> Member Implementations" begins now and runs throughApril 5, 2016. The 
> proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Radosław Pietruszewski via swift-evolution]

As others noted:

* the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift 
would be a lot worse off if only enum cases got their enum types inferred, and 
for any other static member of a type I would have type the fully qualified name
* the leading dot disambiguates the reference for the compiler **and for the 
reader**. I don’t have to guess if I’m not referencing something local, or 
explicitly disambiguate when needed. I just say, “.foo”, and it’s clear.
* I disagree that the rules of lookup are confusing. The feature is poorly 
documented in official guides, but it seems pretty straightforward to me. For 
any context implying T, .foo means a static member T.foo. Like you said, could 
be subjective ¯\_(ツ)_/¯

Best,
— Radek

> On 04 Apr 2016, at 20:05, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Erica Sadun  asked:
> 
>> Can you ping me off-list or in another thread and explain what the
>> issues are?
> 
> All of the following make me uncomfortable with our leading-dot thang:
> 
> * The rules for lookup don't seem obvious to me.  I admit this is very
>  personal/subjective.
> 
> * There is some evidence that people think it means something it doesn't
>  (“enum case”), as mentioned in SE-0036.  That suggests it is a
>  confusing feature.  That confusion may be fairly harmless so far, but
>  still.
> 
> * The dot doesn't seem to buy enough to be worth the complexity it adds
>  to the language; why not just let those names be looked up without the
>  dot?  You can always disambiguate with full qualification if you have
>  to.
> 
> * Static members generally are too verbose to access from within members
>  of a type (`Self.x` doesn't work; you have to write out
>  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
>  so. If we're going to have a special syntax for accessing static
>  members, it should *at least* solve this problem.
> 
> -- 
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Radosław Pietruszewski via swift-evolution]

> What is your evaluation of the proposal?
+1. I like the rule of “don’t make me think”. If I write a piece of code that 
seems correct to me, why would the compiler “intentionally” stop me from 
accepting it? Just smooth out this rough edge and remove one scenario in which 
a compiler error stops me in my work for an error that’s not essential 
complexity.

Yes, the price of it is a slight inconsistency, as this won’t work with `if foo 
{ … } {`. But I seriously doubt anyone would actually *see* this as 
inconsistent. Most programmers would just not be stopped for writing `guard foo 
{ … } else`, and would never notice. No error, no problem :) It’s just that now 
there’s one less place that is a potential error generator ;)

So, yeah, it seems like a fairly straightforward improvement. Not perfect as it 
doesn’t solve anything, but more like “Why not?"

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
Sure, why not ;)

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading, and I’ve roughly followed the initial discussion on the pitch 
as well.

Best,
— Radek

> On 01 Apr 2016, at 05:27, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
> now and runs through April 5, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Jeremy Pereira via swift-evolution]

> On 4 Apr 2016, at 18:18, Haravikk  wrote:
> 
>> 
>> On 4 Apr 2016, at 15:49, Jeremy Pereira  
>> wrote:
>> 
>>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
>>>  wrote:
>>> 
>>> Although I use trailing closures a lot less now, I think I’m a +1 anyway 
>>> for consistency’s sake.
>>> 
>>> I actually really like the idea of having trailing keywords in loops and if 
>>> statements, these needn’t be required (except where a trailing closure is 
>>> used) but for example it means I could do a fully natural language loop 
>>> like:
>>> 
>>> for eachValue in theValues do { … }
>> 
>> This is actually kind of bizarre. Here we are trying to invent new syntax so 
>> that the trailing closure can be used in if/while conditions and for 
>> sequences. However, there is already a perfectly good syntax for putting 
>> closures in these positions: put the closure in the parentheses of the 
>> function call. Are people really so desperate to use trailing closures 
>> everywhere that we have to add new keywords to the language? I don’t think 
>> they are.
> 
> While I kind of agree (and personally prefer the use of parenthesis in most 
> places anyway) it’s an inconsistency to be unable to use them I think. While 
> It’s understandable from a parsing/ambiguity perspective, it’s not really 
> intuitive.

But the resolution would be another inconsistency i.e. a separate keyword that 
is only required if the condition has a trailing closure. Furthermore, that is 
an inconsistency that adds extra complexity to the language.

> 
>>> I like the consistency of every block having a kind of type (do, else, 
>>> defer, catch etc.). 
>> 
>> That is a rabbit hole down which you probably shouldn't go. If we go down 
>> the route of blocks having a “type”, the current situation in Swift becomes 
>> somewhat inconsistent. I would argue that the `else` block on a `guard` is 
>> of a different type to the `else` block on an `if`. If anything, the `else` 
>> block of an `if` is closer to the `then` block. Also, would you allow the 
>> `do` block in a `for` or `while` to have a `catch` block following it? If 
>> not, then these blocks are different to the  existing bare `do` block. 
> 
> Actually that’s not quite what I meant by “type”; while there is a case to be 
> made for unifying these more (else and catch on loops for example) I just 
> meant more along the lines that “do” would always group the main branch, 
> “else” indicates an alternative path if a condition isn’t met and so-on. For 
> the short term however this would just be a case of allowing do on the end to 
> eliminate ambiguity and thus allow trailing closures, but in the long term it 
> could be explored further.

I don’t view the `else` on an `if` as being some kind of second class citizen, 
it’s simply one of two alternate execution paths, whereas the `else` on a 
`guard` really is a second class citizen - it is even restricted what you can 
put in the block i.e. it must cause the enclosing scope to be exited. 

The reason why I called it a rabbit hole is because regarding the keyword in 
front of a block as denoting the kind of block it is, leads us to having to 
change a lot in order to make it meaningful and consistent.

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Andrey Tarantsov via swift-evolution]

> My preference would be for there to be only one Self, and have it always be 
> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
> that onerous to have to write ClassName.foo if that's really what you 
> specifically mean.

+1. There's just no way we want to explain two kinds of Selves to people.

However, we need to make sure it works in these contexts:

1) #selector
2) getting an unbound method
3) referring to static methods (including private ones)

A.

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

Re: [swift-evolution] deployment targets and frameworks

[Andrey Tarantsov via swift-evolution]

Strong +1 on this. Been there myself.

A.

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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Dany St-Amant via swift-evolution]

> Le 31 mars 2016 à 23:41, Douglas Gregor via swift-evolution 
>  a écrit :
> :
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md

Wondering if this fit more in the lexer/in-house coding style bucket.
For the supplied example of "badness", 'case heads', one can also write 'case 
Coins.heads' and with the latest Erica's pitch, one day 'case Self.heads'; are 
these also going to be disallowed?
I have always seen, the leading dot as an opt-in shortcut that the parser 
allowed us to use when the context/type can be inferred, and as such the usage 
of leading dot should probably be left to the user.

The problem I see from the example, is not the inconsistency with 'case heads' 
vs 'case .tails' (as coding style) but that you can define in the enum:

static let bluenose:Coin = .tails

And then use it  in:
var coin:Coin = .bluenose
if coin == .bluenose { print("tails") }

But not in:
switch coin {
case .bluenose: print("tails")
default: print("heads")
}

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

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[Ted F.A. van Gaalen via swift-evolution]

Hi John,

well, I certainly don’t want to return working with C or C++
(I am still recovering from working on C only project on OS/2 
back in 2002 :o) after this little nightmare I always tried 
to avoid as much as possible working on C/C++ 
and also Javascript projects...

Pascal was/is? ok too, I learned OOP with Turbo Pascal 5.5 
in 1989-90. (it should have been Smalltalk but (private) computers
were not fast enough back then) 

If I was given the choice of using either C/C++ or OOP Pascal, 
I would choose Pascal because due to its rigid structure it catches 
a lot of programming errors at compile time instead of run time. 

This is a very important aspect of Swift: 
that it catches a lot of mistakes at compile time!  
I am very grateful for that because it saves me
a lot of trouble at run time, let alone the embarrassment 
of having to solve bugs in already distributed applications 
(of course, you can’t prevent it all) 
Unfortunately this is very hard with “totally free” languages 
like C and C++ are. To me it is almost that C/C++ are a kind 
of super-assemblers and therefore (still?) good for making 
low-level system software. There is an old, albeit ia bit macabre, 
saying that “C and C++ provides all the rope to hang yourself”.. 
However, In the digital domain, for most of us I’d say 
this is very true.

It is also therefore that Pascal has a more fool-proof
for-loop 

  for < variable-name > := < initial_value > to [down to] < final_value >   
  do
 /* statements */ 
  end

...or the 1964  PL/1 variant which has a variable increment/decrement value

   do i = 10 to 5 by -1;/* "by 1" is the default if not specified */
   /*statements*/;
 end;

The variant I am suggesting for Swift is more or less based
on these Pascal and PL/1 implementations because they are safe, 
natural and readable, even for beginners.
Because Swift does not offer easy-to-work-with similar variants
it is regretful that the Swift: 
for  initialization;condition;  increment/decrement

has been removed as written in Proposal nr. 0007, even
before offering a satisfying alternative. 
I still don’t understand why the Swift core team has accepted 
such a proposal,  largely based not on facts
and adequate research, but mostly on very subjective criteria.
Alas, but I have already described my opinion about 
this proposal 0007 in a previous post. 

However to return to the overall topic here: 
Pascal, made by Niklaus Wirth offered imho a 
“reasonable amount” of protecting the programmer 
against one’s self, so that one does not encounter
pitfalls again and again, which does not only happen
with beginning programmers but also with 
experienced digitally active ladies and gentlemen too.

Later on, Niklaus Wirth created Modula-2. 
(and after that also Modula-3) 
If one wants to see really good scope handling then 
take a look how this is implemented in Modula-2 here:
https://en.wikipedia.org/wiki/Modula-2
I think this could be a good base for the modularity
in Swift as well. 

Back then in ca. 1991, I bought a Modula-2 language system
from TDI  for my Atari 520 ST, although I found programming
with Modula-2 on many occasions a bit too restrictive.  
However, I quickly noticed that my apps made with Modula-2
were more stable with very little run time bugs or memory 
runaways.. 

So some protectionism is a good thing, 
this is what Swift offers too, which I really appreciate.
but to what extent does this need to be enforced?
How far does one go? 
Imho, that is exactly what we should discuss.
It is about the range between too rigidly enforcing restrictions
and making a language “totally free” 
Both have it’s pros and cons. 
The art then is, to find the silver path in between
these extremities. A dogmatic approach
(on either side) is not really very helpful.

TedvG


 



 

> On 05.04.2016, at 03:30, John Heerema  wrote:
> 
> Thanks! I enjoyed reading your post today.
> 
> I don’t see having two ways to do something as a weakness, but a strength.
> Again, that’s why weird-old English won out over Esperanto.
> And why messy-old C won out over Pascal and Modula-2 (and, if we’re not 
> careful, Swift).
> 
> Regards,
> John
> 
> From: "Ted F.A. van Gaalen"  >
> Date: Monday, April 4, 2016 at 1:40 PM
> To: John Heerema mailto:jheer...@ucalgary.ca>>
> Cc: swift-evolution  >, Taras Zakharko  >
> Subject: Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations
> 
> Hello John
> I subscribe completely to this point(s) of view!
> TedvG
> 
> 
> 
>> Date: Sun, 3 Apr 2016 19:25:09 +
>> From: John Heerema mailto:jheer...@ucalgary.ca>>
>> To: "swift-evolution@swift.org " 
>> mailto:swift-evolution@swift.org>>
>> Subject: Re: [swift-evolution] Revisiting 0004,0007 etc. - Swift
>> deprecations
>> Message-ID: > >
>> Content-Type: text/plain; charset="window

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution 
>  wrote:
>> Would using another word or symbol fix that problem?
> 
> My preference would be for there to be only one Self, and have it always be 
> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
> that onerous to have to write ClassName.foo if that's really what you 
> specifically mean.

I would agree that Self should remain the dynamic version, but adding 
StaticSelf (however it is spelled) adds the safety of being able to refactor 
code w/o forgetting to rename an explicit class name. It adds the ability to 
more clearly express what you mean (“the containing class/struct, whatever it 
happens to be”), and it would reduce effort while reading code (in that you 
could see quickly that it was StaticSelf instead of having to look to see 
whether it was the same name as the enclosing type every time you read the 
code).

My support for StaticSelf isn’t at all about it being too hard to type 
ClassName.foo the first time, but about being able to read and maintain code 
after the fact.

And, of course, the argument that writing ClassName.foo isn’t onerous is 
dangerously close to an argument for dropping “.foo” with a type inferred by 
the call site... =)

-tim

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

Re: [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Milos Rankovic via swift-evolution]

This could potentially convert to Swift many library developers whose sanity 
depends on type guaranteed sequence sizes. I was just playing with Swift 2.2 
along these lines, and got surprised how far I could get towards that ideal, 
see: http://codereview.stackexchange.com/q/124797/54297 
 

For example, I got this to compile:

let v = Vector<__<_4,_2>,Int>(0)
v.elements.count // 42

let w = Vector<_3,Int>(0)
w.elements // [0, 0, 0]
w[2].value = 5

for x in w {
x // 0, 0, 5
}

Once created, `v` and `w` here can never change size, not even from within the 
implementation.

milos

> On 4 Apr 2016, at 21:10, Brad Hilton via swift-evolution 
>  wrote:
> 
> The Completing Generics Manifesto suggests a more universal solution with 
> generic value parameters which is my vote:
> Generic value parameters
> 
> Currently, Swift’s generic parameters are always types. One could imagine 
> allowing generic parameters that are values, e.g.,
> 
> struct MultiArray { // specify the number of 
> dimensions to the array
>   subscript (indices: Int...) -> T {
> get {
>   require(indices.count == Dimensions)
>   // ...
> }
> }
> 
> A suitably general feature might allow us to express fixed-length array or 
> vector types as a standard library component, and perhaps also allow one to 
> implement a useful dimensional analysis library. Tackling this feature 
> potentially means determining what it is for an expression to be a “constant 
> expression” and diving into dependent-typing, hence the “maybe”.
> 
> > To better support interfacing with lower level systems, like graphics
> > libraries for example, it would be helpful to support the concept of
> > contiguous variables. The most common use case for this would be to create
> > a Matrix struct that can be passed as data into something like Metal. This
> > can be accomplished now, using something like the following:
> > 
> > Current Option 1:
> > 
> > struct Matrix2x2 {
> > var m00: Float
> > var m01: Float
> > var m10: Float
> > var m11: Float
> > }
> > 
> > OR
> > Current Option 2:
> > 
> > struct Matrix2x2 {
> > var m: (Float, Float, Float, Float)
> > }
> > 
> > OR
> > Current Option 3:
> > 
> > struct Matrix2x2 {
> > var m: [Float]
> > }
> > 
> > Options 1&2 allow for the compiler to enforce the fixed number of
> > elements and also for the data to be easily passed into graphics libraries
> > as their memory layout is somewhat predictable using sizeof, strideof, and
> > alignof. The downside is that you lose the ability to easily subscript or
> > iterate the elements.
> > 
> > Option 3 does allow subscripting and iteration, but does not at compile
> > time enforce a fixed number of elements and is not as easily passed into a
> > library that expects to receive the raw data of the matrix.
> > 
> > 
> > Contiguous Variables:
> > 
> > struct Matrix2x2 {
> > var m: Float:2*2
> > }
> > 
> > The variable `m` represents a series of 4 contiguous Float values. The
> > specific number of values must be a compile time constant. The only needed
> > functionality includes `count`, `subscript`, and iteration. To make things
> > easier to implement and to help avoid confusion and more complex
> > documentation, multiple dimensions are not allowed. To define multiple
> > dimensions you must provide your own ordering by wrapping this type in
> > another type and providing a custom subscript implementation. For example:
> > 
> > struct RowMajorMatrix2x2 {
> > var m: Float:2*2
> > 
> > static let rows = 2
> > static let columns = 2
> > 
> > subscript(row: Int, column: Int) ->Float {
> > return m[column * Matrix2x2.rows + row]
> > }
> > }
> > 
> > sizeof(Matrix2x2) is 16
> > strideof(Matrix2x2) is 16
> > 
> > m.count is essentially a compile time constant and is not stored with the
> > rest of the data but is available and can also be used to do runtime bounds
> > checking.
> > 
> > struct Vector3 {
> > var v: Float:3
> > }
> > 
> > sizeof(Vector3) is 12
> > strideof(Vector3) is 12
> > 
> > C code should also now be able to expose data types that contain fixed
> > sized arrays within them.
> > 
> > 
> > 
> ___
> 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-0056: Allow trailing closures in `guard` conditions

[James Richard via swift-evolution]

+1. I feel this fits well with Swift, and the current inconsistency with other 
statements warrants the change.

> On Mar 31, 2016, at 8:27 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
> now and runs through April 5, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams  wrote:
>
> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>
>> [snip]
>>
>> Not included:
>> 1. I know Ranges are in flux, so I've held off on extending Range with
>> a striding(by:) method in this proof-of-concept.
>
> They're not in flux, except for not having been reviewed yet; they are
> settled in the swift-3-indexing-model branch.

Did not know that. Will have to study what's there in more detail.

>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>
> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
> about the meaning of "to" or "through."

I wasn't aware that was the thinking. Limiting strides to
`striding(by:)` removes the ability to express `stride(from: 0, to:
-10, by: -1)` because Range enforces (and it looks like it will
continue to do so in the swift-3-indexing-model branch?) `lowerBound
<= upperBound`, and in a half-open range it's the upper bound that's
excluded.

>> 2. No tests written yet for this proof-of-concept; I noticed that
>> there's a stub for testing strides with bounds of type Double, but
>> there's a comment about things not being ready because Double conforms
>> to RandomIndexType--not sure what to make of that.
>
> Comments in that branch are badly out-of-date.  It's worth trying that,
> especially since there is no RandomAccessIndexType in that branch any
> longer.
>
>> 3. Haven't gotten around to testing performance.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

David Waite stated a major drawback of precedence groups.

People will often create tiny precedence groups for their modules, and user
will find that some of them should actually be the same. They will add
precedenceEqualTo, but all these equivalent groups will still exist. This
problem cannot occur with transitive precedence propagation. So precedence
groups really create more problems than solve.

- Anton

Apr 5, 2016, Антон Жилин wrote:
>
> On the other hand, in your solution you have a list of global rules
> and don't really need braces. How about this?


> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
>
> So precedence group is just a tag that can be used in precedence rules and
> assigned to operators at declaration.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Joe Groff via swift-evolution]

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution 
>  wrote:
> 
> 
>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution 
>>  wrote:
>>> Would using another word or symbol fix that problem?
>> 
>> My preference would be for there to be only one Self, and have it always be 
>> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
>> that onerous to have to write ClassName.foo if that's really what you 
>> specifically mean.
> 
> I would agree that Self should remain the dynamic version, but adding 
> StaticSelf (however it is spelled) adds the safety of being able to refactor 
> code w/o forgetting to rename an explicit class name. It adds the ability to 
> more clearly express what you mean (“the containing class/struct, whatever it 
> happens to be”), and it would reduce effort while reading code (in that you 
> could see quickly that it was StaticSelf instead of having to look to see 
> whether it was the same name as the enclosing type every time you read the 
> code).
> 
> My support for StaticSelf isn’t at all about it being too hard to type 
> ClassName.foo the first time, but about being able to read and maintain code 
> after the fact.

I think you have a good point with your `#Self` idea—there's definitely an 
analogy there to other magic constants like #function.

> And, of course, the argument that writing ClassName.foo isn’t onerous is 
> dangerously close to an argument for dropping “.foo” with a type inferred by 
> the call site... =)

From my own experience with C++11, if it weren't for code completion, having to 
utter 'EnumName::Case' over and over again when working with `enum class`es 
would drive me up the wall.

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

[swift-evolution] [Pitch] Add namespacing to associatedTypes

[Noah Blake via swift-evolution]

Types associated with a protocol are not namespaced by the protocol, but
rather by the protocol's adopters. As such, when two protocols declare a
common associatedType, adoption of those protocols introduces undesirable
ambiguity.

Given the understandable propensity of developers to arrive at similarly
named types (T, for example), it is likely that this problem will reduce
the compatibility of packages for reasons that may not be entirely clear to
the package consumer.

Here is a demonstration of the issue. Apologies, I'm a longtime reader of
the list, but this is my first time posting, and I'm not sure how best to
format this. You may also find this example on Jira (
https://bugs.swift.org/browse/SR-1065).

```
protocol A {
associatedtype T
var aT: T { get }
}

protocol B {
associatedtype T
var bT: T { get }
}
```

T is ambiguous: "Type C does not conform to protocol 'B'."
```
class C: A, B {
var aT = String()
var bT = Int()
}
```


T is inferred unambiguously, compiles without error.
```
class C: A, B {
var aT = String()
var bT = String()
}
```

T is explicit, but problematic: "Type C does not conform to protocol 'A'."
```
class C: A, B {
typealias T = Int
var aT = String()
var bT = Int()
}
```

I would greatly appreciate any advice or direction as to next steps. I have
a proposal for resolving this in mind, but it seemed premature to offer it
before finding some agreement that this was worth carrying forward.

Best regards,
Noah Blake
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 10:06 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution 
>>>  wrote:
 Would using another word or symbol fix that problem?
>>> 
>>> My preference would be for there to be only one Self, and have it always be 
>>> the dynamic type of 'self'. Some people disagree, but I don't think it's 
>>> all that onerous to have to write ClassName.foo if that's really what you 
>>> specifically mean.
>> 
>> I would agree that Self should remain the dynamic version, but adding 
>> StaticSelf (however it is spelled) adds the safety of being able to refactor 
>> code w/o forgetting to rename an explicit class name. It adds the ability to 
>> more clearly express what you mean (“the containing class/struct, whatever 
>> it happens to be”), and it would reduce effort while reading code (in that 
>> you could see quickly that it was StaticSelf instead of having to look to 
>> see whether it was the same name as the enclosing type every time you read 
>> the code).
>> 
>> My support for StaticSelf isn’t at all about it being too hard to type 
>> ClassName.foo the first time, but about being able to read and maintain code 
>> after the fact.
> 
> I think you have a good point with your `#Self` idea—there's definitely an 
> analogy there to other magic constants like #function.

This also falls nicely into my list of "debug literals we discussed on-list as 
wanting to see but did nothing about". (I would also like to see #function 
upgraded to use full gregorized naming with arguments. )

-- E

> 
>> And, of course, the argument that writing ClassName.foo isn’t onerous is 
>> dangerously close to an argument for dropping “.foo” with a type inferred by 
>> the call site... =)
> 
> From my own experience with C++11, if it weren't for code completion, having 
> to utter 'EnumName::Case' over and over again when working with `enum 
> class`es would drive me up the wall.
> 
> -Joe
> ___
> 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] deployment targets and frameworks

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 4:48 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> Suppose *Apple* ships a framework that is only supported in iOS 9.3.  As a 
> direct consequence, the framework is only #available in iOS 9.3 or later.
> 
> Suppose Jane links this framework into her iOS application.  The deployment 
> target for her application *can be any value*.  She sets the framework to be 
> weakly linked, and as long as the code that uses the Apple framework is 
> guarded by a 9.3 availability check, she can deploy back to 8.0, 7.0, etc.
> 
> Suppose *I* ship a custom framework that I only want to bother supporting for 
> iOS 9.3 users.  I'm not testing on old OS, I don't have CI on old OS, and 
> quite frankly I have no idea if it works.  And I'm not in the habit of 
> shipping code that wasn't even tested on my machine.  As a direct 
> consequence, I set my framework deployment target to 9.3.
> 
> Now Jane links this framework into her "deployment target 8.0" application.  
> She weakly links it and uses availability checks just like she did with the 
> Apple framework.  But this time the compiler says no:
> 
> error: module file's minimum deployment target is ios9.3 v9.3
> 
> Jane now has a set of bad choices:
> 
> 1.  She can not use my framework at all
> 2.  She can drop support for <9.3 entirely from her application in order to 
> use my framework
> 3.  She can convince me to support iOS 8, when I don't want to invest in the 
> QA and test time.
> 4.  She can convince me to set my deployment target to 8, try to find all my 
> public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I didn't 
> miss any.  Spoiler alert: that's what I did all afternoon.
> 
> This is too hard.  IMO Jane should be able to use my "9.3+" frameworks as 
> easily as she can use Apple's.
> 
> IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0" application, 
> it should A) import successfully, B) link weakly, and C) have 
> `@availability(9.3, *)` overlayed on the interface.

I would not want this to be implicit behavior: it should be recorded in the 
source with, e.g.,

@availability(iOS: 9.3) import YourCustomFramework

so that it is clear that the imported declarations are only available on iOS 
9.3 or newer.

- Doug


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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>> 
>> There are a number of things I'm not really clear on.
>> 
>> * * *
>> 
>> Consider this Objective-C API:
>> 
>>  ObjCFizzer* myFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>>  var myFizzer: ObjCFizzer
>>  var myFizzer: Fizzer
> 
> The latter. The idea is that the importer sees the bridged type is available 
> and substitutes it on all imported signatures. The actual mechanics of that 
> will involve some generated code (thunk) to call the protocol. I could update 
> the proposal to include what the body of that thunk might look like but it 
> didn’t seem terribly interesting.

Right. There will be some thunking the compiler does.

>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this 
>> Objective-C API:
>> 
>>  ObjCMutableFizzer* mutableFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>>  var myMutableFizzer: ObjCMutableFizzer
>>  var myMutableFizzer: Fizzer
> 
> The intention there is that it imports as the bridged type so the latter.

I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would be 
the former.

> 
> 
>> 
>> On the basis of NSArray and friends, I assume they come across like this:
>> 
>>  var myFizzer: Fizzer
>>  var myMutableFizzer: ObjCMutableFizzer
>> 
>> Is that correct?
> 
> No

I would have said “yes" ;)

>> 
>> * * *
>> 
>> Foundation classes can sometimes be bridged using an upcast (a plain `as`), 
>> which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? 
>> If not, will Foundation classes lose that ability?
>> 
>> If this feature can't be expressed with ObjectiveCBridgeable, is this seen 
>> as a shortcoming we should try to overcome, or the proper design? I worry 
>> about the unnecessary proliferation of exclamation points, especially since 
>> many style guides strongly discourage them, which will turn this into an 
>> unnecessary proliferation of unnecessary `if let`s.
> 
> This would not be possible. This sort of bridging only works with special 
> magic types because they are known to always succeed. There is no condition 
> under which Swift will fail to convert String to NSString. The 
> compiler/runtime can’t prove that about any arbitrary type.

We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the 
entry-point

func bridgeToObjectiveC() -> ObjectiveCType


> For bridging an Objective-C library into Swift, ideally all the APIs will be 
> annotated with SWIFT_BRIDGED so on import the Swift code won’t even be aware 
> the Objective-C type exists. All you’ll see in Swift is the appropriate Swift 
> types. This gives a library (say Photos.framework or UIKit) the chance to 
> provide truly native Swift types by shipping a module with combined Swift and 
> Objective-C code.
> 
> Similarly, going the other direction (an app with Objective-C and Swift code) 
> this proposal eliminates the need to deal with the Objective-C types in Swift.

The ObjC types will still exist (unless explicitly banned via 
NS_UNAVAILABLE_IN_SWIFT or similar), and can leak through in some cases (e.g., 
UnsafeMutablePointer).

- Doug

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Austin Zheng via swift-evolution]

I too would like a #Self. In my (subjective, biased) experience, sufficiently 
descriptive type names are usually long enough to make working with static 
members painfully onerous.

If there's still the risk of confusion (compile-time type versus runtime type), 
maybe #Self can be limited to instances where the type it references cannot 
change at runtime (e.g. a struct, enum, or final class). I don't know if this 
will actually be necessary, though - just throwing ideas out there.

Austin

> On Apr 5, 2016, at 9:06 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution 
>>>  wrote:
 Would using another word or symbol fix that problem?
>>> 
>>> My preference would be for there to be only one Self, and have it always be 
>>> the dynamic type of 'self'. Some people disagree, but I don't think it's 
>>> all that onerous to have to write ClassName.foo if that's really what you 
>>> specifically mean.
>> 
>> I would agree that Self should remain the dynamic version, but adding 
>> StaticSelf (however it is spelled) adds the safety of being able to refactor 
>> code w/o forgetting to rename an explicit class name. It adds the ability to 
>> more clearly express what you mean (“the containing class/struct, whatever 
>> it happens to be”), and it would reduce effort while reading code (in that 
>> you could see quickly that it was StaticSelf instead of having to look to 
>> see whether it was the same name as the enclosing type every time you read 
>> the code).
>> 
>> My support for StaticSelf isn’t at all about it being too hard to type 
>> ClassName.foo the first time, but about being able to read and maintain code 
>> after the fact.
> 
> I think you have a good point with your `#Self` idea—there's definitely an 
> analogy there to other magic constants like #function.
> 
>> And, of course, the argument that writing ClassName.foo isn’t onerous is 
>> dangerously close to an argument for dropping “.foo” with a type inferred by 
>> the call site... =)
> 
> From my own experience with C++11, if it weren't for code completion, having 
> to utter 'EnumName::Case' over and over again when working with `enum 
> class`es would drive me up the wall.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

[Milos Rankovic via swift-evolution]

I agree that this is counterintuitive behaviour and should ideally be changed 
to match things like:

func f  (_: T.Type) {}
func f2  (_: T.Type) {}

f(Int)
f2(String)

milos

> On 5 Apr 2016, at 17:16, Noah Blake via swift-evolution 
>  wrote:
> 
> Types associated with a protocol are not namespaced by the protocol, but 
> rather by the protocol's adopters. As such, when two protocols declare a 
> common associatedType, adoption of those protocols introduces undesirable 
> ambiguity.
> 
> Given the understandable propensity of developers to arrive at similarly 
> named types (T, for example), it is likely that this problem will reduce the 
> compatibility of packages for reasons that may not be entirely clear to the 
> package consumer.
> 
> Here is a demonstration of the issue. Apologies, I'm a longtime reader of the 
> list, but this is my first time posting, and I'm not sure how best to format 
> this. You may also find this example on Jira 
> (https://bugs.swift.org/browse/SR-1065 
> ).
> 
> ```
> protocol A {
> associatedtype T
> var aT: T { get }
> }
> 
> protocol B {
> associatedtype T
> var bT: T { get }
> }
> ```
> 
> T is ambiguous: "Type C does not conform to protocol 'B'."
> ```
> class C: A, B {
> var aT = String()
> var bT = Int()
> }
> ```
> 
> 
> T is inferred unambiguously, compiles without error.
> ```
> class C: A, B {
> var aT = String()
> var bT = String()
> }
> ```
> 
> T is explicit, but problematic: "Type C does not conform to protocol 'A'."
> ```
> class C: A, B {
> typealias T = Int
> var aT = String()
> var bT = Int()
> }
> ```
> 
> I would greatly appreciate any advice or direction as to next steps. I have a 
> proposal for resolving this in mind, but it seemed premature to offer it 
> before finding some agreement that this was worth carrying forward.
> 
> Best regards,
> Noah Blake
> ___
> 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-0058: Allow Swift types to provide custom Objective-C representations

[Russ Bishop via swift-evolution]

> On Apr 5, 2016, at 10:14 AM, Douglas Gregor  wrote:
>> 
>>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this 
>>> Objective-C API:
>>> 
>>> ObjCMutableFizzer* mutableFizzer;
>>> 
>>> Which of these represents how it is imported?
>>> 
>>> var myMutableFizzer: ObjCMutableFizzer
>>> var myMutableFizzer: Fizzer
>> 
>> The intention there is that it imports as the bridged type so the latter.
> 
> I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would be 
> the former.
> 

Hmmm… So all subclasses are hidden as far as the interface is concerned (and 
the ambiguity rules)? I’m fine with that, it seems like it suites the class 
cluster approach just fine.


> 
>>> 
>>> * * *
>>> 
>>> Foundation classes can sometimes be bridged using an upcast (a plain `as`), 
>>> which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? 
>>> If not, will Foundation classes lose that ability?
>>> 
>>> If this feature can't be expressed with ObjectiveCBridgeable, is this seen 
>>> as a shortcoming we should try to overcome, or the proper design? I worry 
>>> about the unnecessary proliferation of exclamation points, especially since 
>>> many style guides strongly discourage them, which will turn this into an 
>>> unnecessary proliferation of unnecessary `if let`s.
>> 
>> This would not be possible. This sort of bridging only works with special 
>> magic types because they are known to always succeed. There is no condition 
>> under which Swift will fail to convert String to NSString. The 
>> compiler/runtime can’t prove that about any arbitrary type.
> 
> We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the 
> entry-point
> 
>   func bridgeToObjectiveC() -> ObjectiveCType
> 

It does seem strange that this is asymmetrical but I don’t know that it is 
worth the complexity to introduce an extended protocol to declare a type has a 
bi-directional always-succeeds bridging conversion.


> 
>> For bridging an Objective-C library into Swift, ideally all the APIs will be 
>> annotated with SWIFT_BRIDGED so on import the Swift code won’t even be aware 
>> the Objective-C type exists. All you’ll see in Swift is the appropriate 
>> Swift types. This gives a library (say Photos.framework or UIKit) the chance 
>> to provide truly native Swift types by shipping a module with combined Swift 
>> and Objective-C code.
>> 
>> Similarly, going the other direction (an app with Objective-C and Swift 
>> code) this proposal eliminates the need to deal with the Objective-C types 
>> in Swift.
> 
> The ObjC types will still exist (unless explicitly banned via 
> NS_UNAVAILABLE_IN_SWIFT or similar), and can leak through in some cases 
> (e.g., UnsafeMutablePointer).
> 
>   - Doug

Agreed, that’s what I meant by "things like performSelector, context objects, 
…” :)


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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Russ Bishop via swift-evolution]

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution 
>  wrote:
> 
> 
>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> Would using another word or symbol fix that problem?
>> 
>> My preference would be for there to be only one Self, and have it always be 
>> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
>> that onerous to have to write ClassName.foo if that's really what you 
>> specifically mean.
> 
> I would agree that Self should remain the dynamic version, but adding 
> StaticSelf (however it is spelled) adds the safety of being able to refactor 
> code w/o forgetting to rename an explicit class name. It adds the ability to 
> more clearly express what you mean (“the containing class/struct, whatever it 
> happens to be”), and it would reduce effort while reading code (in that you 
> could see quickly that it was StaticSelf instead of having to look to see 
> whether it was the same name as the enclosing type every time you read the 
> code).

But if you don’t want subclasses to override it then why are you making it 
internal/public in the first place?

I’m not sure the only-classes case of exposing a class/static publicly but also 
not wanting subclasses to override it justifies a new language construct. 
Accessing these things via Self (aka self.dynamicType) seems good enough to me.


Russ


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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Douglas Gregor via swift-evolution]

> On Apr 5, 2016, at 11:36 AM, Russ Bishop  wrote:
> 
> 
>> On Apr 5, 2016, at 10:14 AM, Douglas Gregor > > wrote:
>>> 
 Suppose there is also a subclass (say, ObjCMutableFizzer), and we have 
 this Objective-C API:
 
ObjCMutableFizzer* mutableFizzer;
 
 Which of these represents how it is imported?
 
var myMutableFizzer: ObjCMutableFizzer
var myMutableFizzer: Fizzer
>>> 
>>> The intention there is that it imports as the bridged type so the latter.
>> 
>> I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would 
>> be the former.
>> 
> 
> Hmmm… So all subclasses are hidden as far as the interface is concerned (and 
> the ambiguity rules)? I’m fine with that, it seems like it suites the class 
> cluster approach just fine.

Not “hidden”; they’re accessible and not bridged.

>> 
 
 * * *
 
 Foundation classes can sometimes be bridged using an upcast (a plain 
 `as`), which cannot crash. Is this possible with ObjectiveCBridgeable? If 
 so, how? If not, will Foundation classes lose that ability?
 
 If this feature can't be expressed with ObjectiveCBridgeable, is this seen 
 as a shortcoming we should try to overcome, or the proper design? I worry 
 about the unnecessary proliferation of exclamation points, especially 
 since many style guides strongly discourage them, which will turn this 
 into an unnecessary proliferation of unnecessary `if let`s.
>>> 
>>> This would not be possible. This sort of bridging only works with special 
>>> magic types because they are known to always succeed. There is no condition 
>>> under which Swift will fail to convert String to NSString. The 
>>> compiler/runtime can’t prove that about any arbitrary type.
>> 
>> We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the 
>> entry-point
>> 
>>  func bridgeToObjectiveC() -> ObjectiveCType
>> 
> 
> It does seem strange that this is asymmetrical but I don’t know that it is 
> worth the complexity to introduce an extended protocol to declare a type has 
> a bi-directional always-succeeds bridging conversion.

It is a little odd; we have isBridgedToObjectiveC and bridgeToObjectiveC, where 
we could possibly have the latter produce an ObjectiveCType? and remove the 
former.

- Doug

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

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

> Am 05.04.2016 um 17:29 schrieb Антон Жилин :
> 
> David Waite stated a major drawback of precedence groups.
> 
> People will often create tiny precedence groups for their modules, and user 
> will find that some of them should actually be the same. They will add 
> precedenceEqualTo, but all these equivalent groups will still exist. This 
> problem cannot occur with transitive precedence propagation. So precedence 
> groups really create more problems than solve.
> 
> - Anton

Do you mean these drawbacks?

"
> However, this may create more issues than it solves (two frameworks creating 
> their own custom operators, putting them in custom precedence groups, and the 
> consumer decides the two precedence groups are really equivalent)
> 
> -DW
"

What is the problem? Changing the relative precedence of external operators in 
your file? Doesn't the same "problem" occur in your proposal (only with one 
operator)?

What is the difference between overriding an operator function like this:

func + (l: Int, r: Int) -> Int {
   return 0
}

This can also mess up your code...
I'm sorry if I haven't understood your point.

From the other email:

> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky? 
> Maybe:
> 
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
> 
> It also solves my concern about dictionary inside braces.

I prefer "precedence(+ lessThan *)". However I don't think it's Swift style 
since "lessThan" is like an infix operator with letters although the symmetry 
between "+" and "*" would be nicely handled by such operator.

> Precedence groups have a great benefit of additional symmetry. Transitive 
> precedence propagation, on the other hand, also has benefits:
> 
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take 
> precedence and precedenceGroup as keywords, that's why I originally preferred 
> directives

Both 1 and 2 are true but I still prefer to use declarations since they provide 
exactly one location where to put operators with equal precedence.

By the way "precedence" is already a keyword... One more to go :)

> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`, I'd 
> rather say that I want it to have priority of plus and minus, not "belong to 
> multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be more 
> difficult to invent some name for their group like FunctorManipulator.
> 

I think this deserves more discussion:
Should we allow "precedence(... equalTo ...)" for operators if we have 
precedence groups?

Such a precedence declaration would be contrary to my argument above: declare 
equal operator precedences in one place, which is more maintainable.

> On the other hand, in your solution you have a list of global rules and don't 
> really need braces. How about this?
> 
> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
> 
> So precedence group is just a tag that can be used in precedence rules and 
> assigned to operators at declaration.

Although it is consistent with your proposal for me it is too much repetition 
and "code noise". Compare:

infix operator + { associativity: left }
infix operator * { associativity: left }
infix operator <> {}
precedenceGroup Additive { + }
precedenceGroup Multiplicative { * }
precedence(Additive lessThan Multiplicative)

Which is in my opinion way more readable even without syntax highlighting.


Thank You for sharing Your thoughts which have enriched me! :)

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Xiaodi Wu  wrote:

> On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams  wrote:
>>
>> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>>
>>> [snip]
>>>
>>> Not included:
>>> 1. I know Ranges are in flux, so I've held off on extending Range with
>>> a striding(by:) method in this proof-of-concept.
>>
>> They're not in flux, except for not having been reviewed yet; they are
>> settled in the swift-3-indexing-model branch.
>
> Did not know that. Will have to study what's there in more detail.
>
>>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>>
>> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
>> about the meaning of "to" or "through."
>
> I wasn't aware that was the thinking. Limiting strides to
> `striding(by:)` removes the ability to express `stride(from: 0, to:
> -10, by: -1)` 

IMO this:

  (-9...0).reverse()

is better than 

  stride(from: 0, to: -10, by: -1)

What do you think?

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 5, 2016, at 11:41 AM, Russ Bishop  wrote:
> 
> But if you don’t want subclasses to override it then why are you making it 
> internal/public in the first place?

I'm wan’t talking about overriding it… In my earlier posts I was talking about 
subclasses being able to call a utility function on their superclass and have a 
generic be expanded to the subclass type (whatever it is) by using `#Self`.

So, if the superclass `PropertyOwner ` has something like this (excusing typos 
since this code can’t be compiled right now, obviously =) ...

static func property(ownerType: 
Owner.Type = #Self.self, name: String, value: ValueType)

then a subclass `Sub` could do:

static let foozle = property(name: “foozle”, value: Int(3))

and end up with `foozle` being configured with ownerType = Sub.self. If later 
this property is moved to a different class, its ownerType would automatically 
change based on its new scope.

-tim

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Certainly, for integer literals and strides of -1.

I meant more generally that removal of stride(...) will eliminate the
possibility of striding to but not through arbitrary half-open intervals
(a, b], where a < b, by a negative increment, because there is no such
thing as `a>..b` to express such an interval as a Swift range.

Of course, all such cases can be handled by adjusting the endpoint and
using a closed range instead, but the same can be said for all half-open
ranges.
On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams  wrote:

>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams 
> wrote:
> >>
> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> >>
> >>> [snip]
> >>>
> >>> Not included:
> >>> 1. I know Ranges are in flux, so I've held off on extending Range with
> >>> a striding(by:) method in this proof-of-concept.
> >>
> >> They're not in flux, except for not having been reviewed yet; they are
> >> settled in the swift-3-indexing-model branch.
> >
> > Did not know that. Will have to study what's there in more detail.
> >
> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> >>
> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
> >> about the meaning of "to" or "through."
> >
> > I wasn't aware that was the thinking. Limiting strides to
> > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > -10, by: -1)`
>
> IMO this:
>
>   (-9...0).reverse()
>
> is better than
>
>   stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> --
> Dave
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Milos Rankovic via swift-evolution]

> On 5 Apr 2016, at 20:54, Dave Abrahams via swift-evolution 
>  wrote:
> 
> IMO this:
> 
>  (-9...0).reverse()
> 
> is better than 
> 
>  stride(from: 0, to: -10, by: -1)
> 
> What do you think?
> 
> -- 
> Dave

Are we absolutely certain that an operator could not be found such that (I use 
`<` and `>` here for illustrative purposes only):

for i in 1...5 > 2 {
i // 1, 3, 5
}

for i in 1...5 < 2 {
i // 5, 3, 1
}

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Howard Lovatt via swift-evolution]

I much prefer (0 ... -9).by(-1) and  (0 ..< -10).by(-1)

On Wednesday, 6 April 2016, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams  > wrote:
> >>
> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> >>
> >>> [snip]
> >>>
> >>> Not included:
> >>> 1. I know Ranges are in flux, so I've held off on extending Range with
> >>> a striding(by:) method in this proof-of-concept.
> >>
> >> They're not in flux, except for not having been reviewed yet; they are
> >> settled in the swift-3-indexing-model branch.
> >
> > Did not know that. Will have to study what's there in more detail.
> >
> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> >>
> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
> >> about the meaning of "to" or "through."
> >
> > I wasn't aware that was the thinking. Limiting strides to
> > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > -10, by: -1)`
>
> IMO this:
>
>   (-9...0).reverse()
>
> is better than
>
>   stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> --
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Added

group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs
would be allowed there.

> Should we allow "precedence(... equalTo ...)" for operators if we have
precedence groups?
I think no.

I have a question to your group syntax.
Since all operators in a precedence group must have equal associativity for
parsing to work and look logically (right?), wouldn't it be better to
declare associativity in groups?
If so, then body of operator declaration won't contain anything, and we can
remove it:

precedenceGroup Additive {
associativity(left)
+, -
}
infix operator +
infix operator -

Does this body of precedenceGroup look OK from syntactic PoV?

Now, I have another idea.
As operator declarations themselves don't contain anything anymore, remove
operator declarations at all. We don't need to pre-declare function names,
for example.
Next, `precedenceGroup` could be as well replaced with `precedenceLevel`,
or just `precedence`, and I would not worry about additional keywords.
So, our example would look like this:

precedence Additive {
associativity(left)
+, -
}
precedence Multiplicative {
associativity(left)
*, /
}
precedence(Additive < Multiplicative)

As a future direction, we could add extensions to precedence levels.
We could go further and replace `precedence` with `operator`, abandoning
the idea of priority for prefix and postfix operators (that I honestly
don't like).

infix operator Additive {
members(+, -)
associativity(left)
}
infix operator Multiplicative {
members(*, /)
associativity(left)
precedence(> Additive)
}

Some other questions:
Do we need transitive precedence propagation?
Do we need resolution of conflicts, i.e. merging multiple definitions of
same operators and groups, where possible?

2016-04-05 22:52 GMT+03:00 Maximilian Hünenberger :

>
> Am 05.04.2016 um 17:29 schrieb Антон Жилин :
>
> David Waite stated a major drawback of precedence groups.
>
> People will often create tiny precedence groups for their modules, and
> user will find that some of them should actually be the same. They will add
> precedenceEqualTo, but all these equivalent groups will still exist. This
> problem cannot occur with transitive precedence propagation. So precedence
> groups really create more problems than solve.
>
> - Anton
>
>
> Do you mean these drawbacks?
>
> "
>
> However, this may create more issues than it solves (two frameworks
> creating their own custom operators, putting them in custom precedence
> groups, and the consumer decides the two precedence groups are really
> equivalent)
>
> -DW
>
> "
>
> What is the problem? Changing the relative precedence of external
> operators in your file? Doesn't the same "problem" occur in your proposal
> (only with one operator)?
>
> What is the difference between overriding an operator function like this:
>
> func + (l: Int, r: Int) -> Int {
>return 0
> }
>
> This can also mess up your code...
> I'm sorry if I haven't understood your point.
>
> From the other email:
>
> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
> Maybe:
>
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
>
> It also solves my concern about dictionary inside braces.
>
>
> I prefer "precedence(+ lessThan *)". However I don't think it's Swift
> style since "lessThan" is like an infix operator *with letters *although
> the symmetry between "+" and "*" would be nicely handled by such operator.
>
> Precedence groups have a great benefit of additional symmetry. Transitive
> precedence propagation, on the other hand, also has benefits:
>
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take
> precedence and precedenceGroup as keywords, that's why I
> originally preferred directives
>
>
> Both 1 and 2 are true but I still prefer to use declarations since they
> provide exactly one location where to put operators with equal precedence.
>
> By the way "precedence" is already a keyword... One more to go :)
>
> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`,
> I'd rather say that I want it to have priority of plus and minus, not
> "belong to multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be
> more difficult to invent some name for their group like FunctorManipulator.
>
>
> I think this deserves more discussion:
> Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
>
> Such a precedence declaration would be contrary to my argument above:
> declare equal operator precedences in one place, which is more maintainable.
>
> On the other hand, in your solution you have a list of global rules
> and don't re

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Howard, the point I am raising is that `0...(-9)` is not valid Swift
because the first, "lower" bound is enforced to be less than the second,
"upper" bound.

The problem is that with that restriction certain types of half-open
intervals, namely those where the lower bound is the one being excluded,
cannot be represented as a Range either currently or in Dave A's branch.
On Tue, Apr 5, 2016 at 3:30 PM Howard Lovatt 
wrote:

> I much prefer (0 ... -9).by(-1) and  (0 ..< -10).by(-1)
>
> On Wednesday, 6 April 2016, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>>
>> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams 
>> wrote:
>> >>
>> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>> >>
>> >>> [snip]
>> >>>
>> >>> Not included:
>> >>> 1. I know Ranges are in flux, so I've held off on extending Range with
>> >>> a striding(by:) method in this proof-of-concept.
>> >>
>> >> They're not in flux, except for not having been reviewed yet; they are
>> >> settled in the swift-3-indexing-model branch.
>> >
>> > Did not know that. Will have to study what's there in more detail.
>> >
>> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>> >>
>> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
>> >> about the meaning of "to" or "through."
>> >
>> > I wasn't aware that was the thinking. Limiting strides to
>> > `striding(by:)` removes the ability to express `stride(from: 0, to:
>> > -10, by: -1)`
>>
>> IMO this:
>>
>>   (-9...0).reverse()
>>
>> is better than
>>
>>   stride(from: 0, to: -10, by: -1)
>>
>> What do you think?
>>
>> --
>> Dave
>>
> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> --
> -- Howard.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Howard Lovatt via swift-evolution]

Yes I know what you are saying and I am suggesting changing that so that:

 (0 ... -9) and  (0 ..< -10)

Are both empty ranges rather than errors because they implicitly have a
'by' of 1.

On Wednesday, 6 April 2016, Xiaodi Wu  wrote:

> Howard, the point I am raising is that `0...(-9)` is not valid Swift
> because the first, "lower" bound is enforced to be less than the second,
> "upper" bound.
>
> The problem is that with that restriction certain types of half-open
> intervals, namely those where the lower bound is the one being excluded,
> cannot be represented as a Range either currently or in Dave A's branch.
> On Tue, Apr 5, 2016 at 3:30 PM Howard Lovatt  > wrote:
>
>> I much prefer (0 ... -9).by(-1) and  (0 ..< -10).by(-1)
>>
>> On Wednesday, 6 April 2016, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>>
>>>
>>> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>>>
>>> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams 
>>> wrote:
>>> >>
>>> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>>> >>
>>> >>> [snip]
>>> >>>
>>> >>> Not included:
>>> >>> 1. I know Ranges are in flux, so I've held off on extending Range
>>> with
>>> >>> a striding(by:) method in this proof-of-concept.
>>> >>
>>> >> They're not in flux, except for not having been reviewed yet; they are
>>> >> settled in the swift-3-indexing-model branch.
>>> >
>>> > Did not know that. Will have to study what's there in more detail.
>>> >
>>> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>>> >>
>>> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
>>> >> about the meaning of "to" or "through."
>>> >
>>> > I wasn't aware that was the thinking. Limiting strides to
>>> > `striding(by:)` removes the ability to express `stride(from: 0, to:
>>> > -10, by: -1)`
>>>
>>> IMO this:
>>>
>>>   (-9...0).reverse()
>>>
>>> is better than
>>>
>>>   stride(from: 0, to: -10, by: -1)
>>>
>>> What do you think?
>>>
>>> --
>>> Dave
>>>
>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>> --
>> -- Howard.
>>
>

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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Joe Groff  wrote:

> Hello Swift community,
>
> The review of “Allow Swift types to provide custom Objective-C 
> representations”
> begins now and runs through April 11, 2016. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reviews are an important part of the Swift evolution process. All reviews 
> should
> be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager. When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through
> constructive criticism and, eventually, determine the direction of Swift. When
> writing your review, here are some questions you might want to answer in your
> review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how do
> you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or 
> an
> in-depth study?

A few thoughts: 

1. It would have made it easier to evaluate if the proposal had not
   talked about removing _ObjectiveCBridgeable and replacing it with a
   new ObjectiveCBridgeable protocol, but what could more accurately be
   described as de-underscoring the existing protocol and slightly
   modernizing its API.  The existing protocol was always intended to be
   suitable for general use this way, and the design remains
   substantially unchanged, so I support the proposal in principle.

2. These two APIs should look different IMO:

  init?(bridgedFromObjectiveC: ObjectiveCType)
  init(unconditionallyBridgedFromObjectiveC: ObjectiveCType?)

they should definitely use “bridging” instead of “bridged,” since the
phrase describes *how* the conversion is going to be done.

  init?(bridgingFromObjectiveC: ObjectiveCType)
  init(unconditionallyBridgingFromObjectiveC: ObjectiveCType?)

Then, the “ObjectiveC” in the names looks like redundant type
information, suggesting this would be better:

  init?(bridgingFrom: ObjectiveCType)
  init(unconditionallyBridgingFrom: ObjectiveCType?)

But then, these *are* intended to be full-width type conversions,
are they not?  Why not these:

  init?(_ source: ObjectiveCType)
  init(_ source: ObjectiveCType?)

?  If any of these transformations are wrong, it would good to have
a rationale as to why.


3. Is this proposal introducing a backdoor people can exploit to create
   user-defined implicit conversions?  If so, shouldn't that worry us?

4. This proposal should probably support creating a type that only
   bridges *from* Objective-C, to handle bridging mutable Objective-C
   classes without an immutable base class to value types (anything else
   breaks one of the languages' expectations of value or reference
   semantics).  This suggests a hierarchy of two protocols might be
   warranted.

5. For the version of the protocol that does bridge back to Objective-C,
   maybe something should be done to make it more clear that the
   ObjectiveCType must be immutable.  Perhaps that means doing this
   without a protocol hierarchy and using a different associated type
   name in the two protocols; I don't know.

-- 
Dave

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Xiaodi Wu  wrote:

> Certainly, for integer literals and strides of -1.
>
> I meant more generally that removal of stride(...) will eliminate the
> possibility of striding to but not through arbitrary half-open intervals (a, 
> b],
> where a < b, by a negative increment, because there is no such thing as 
> `a>..b`
> to express such an interval as a Swift range.
> Of course, all such cases can be handled by adjusting the endpoint and using a
> closed range instead
>

Indeed, if b - a is a multiple of s,

   (a+s...b).striding(by: s).reversed

works.  

The question is whether this case is important enough to create a
special family of functions for, and then deal with the naming issues
raised by
https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
?

> On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
>  wrote:
>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
>  wrote:
> >>
> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> >>
> >>> [snip]
> >>>
> >>> Not included:
> >>> 1. I know Ranges are in flux, so I've held off on extending Range with
> >>> a striding(by:) method in this proof-of-concept.
> >>
> >> They're not in flux, except for not having been reviewed yet; they are
> >> settled in the swift-3-indexing-model branch.
> >
> > Did not know that. Will have to study what's there in more detail.
> >
> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> >>
> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
> >> about the meaning of "to" or "through."
> >
> > I wasn't aware that was the thinking. Limiting strides to
> > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > -10, by: -1)`
>
> IMO this:
>
> (-9...0).reverse()
>
> is better than
>
> stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Xiaodi Wu  wrote:

> Certainly, for integer literals and strides of -1.
>
> I meant more generally that removal of stride(...) will eliminate the
> possibility of striding to but not through arbitrary half-open intervals (a, 
> b],
> where a < b, by a negative increment, because there is no such thing as 
> `a>..b`
> to express such an interval as a Swift range.

That would clearly be

 a<..b

if it was needed, neh?

>
> Of course, all such cases can be handled by adjusting the endpoint and using a
> closed range instead, but the same can be said for all half-open ranges.
>
> On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
>  wrote:
>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
>  wrote:
> >>
> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> >>
> >>> [snip]
> >>>
> >>> Not included:
> >>> 1. I know Ranges are in flux, so I've held off on extending Range with
> >>> a striding(by:) method in this proof-of-concept.
> >>
> >> They're not in flux, except for not having been reviewed yet; they are
> >> settled in the swift-3-indexing-model branch.
> >
> > Did not know that. Will have to study what's there in more detail.
> >
> >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> >>
> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
> >> about the meaning of "to" or "through."
> >
> > I wasn't aware that was the thinking. Limiting strides to
> > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > -10, by: -1)`
>
> IMO this:
>
> (-9...0).reverse()
>
> is better than
>
> stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

[David Hart via swift-evolution]

I think TOML is no-go as its readme says:

Be warned, this spec is still changing a lot. Until it's marked as 1.0, you 
should assume that it is unstable and act accordingly.

And I agree about YAML: no parser, more work, and more complicated.

JSON sounds like a sane format.

> On 04 Apr 2016, at 19:41, Max Howell via swift-evolution 
>  wrote:
> 
>> This is a very welcome addition. Thanks!
>> 
>> A nitpicky detail: I’d prefer the format for the lock file to be yaml or 
>> toml over json, since those read a little easier in git diffs (which is, in 
>> my experience with cocoapods lockfiles, the only place I ever interact with 
>> the lockfiles contents).
> 
> Probably we could do TOML.
> 
> I picked JSON because it is a more familiar and more widely supported (by 
> tools) format.
> 
> YAML would be more work since we have no available YAML parser.
> 
> ___
> 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] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Howard Lovatt  wrote:

> Yes I know what you are saying and I am suggesting changing that so that:
>
> (0 ... -9) and (0 ..< -10)
>
> Are both empty ranges rather than errors because they implicitly have a 'by' 
> of
> 1. 

What are the startIndex and endIndex of these ranges when viewed as
Collections?  Remember, for an empty collection startIndex == endIndex
is an invariant.

>
> On Wednesday, 6 April 2016, Xiaodi Wu
>  wrote:
>
> Howard, the point I am raising is that `0...(-9)` is not valid Swift 
> because
> the first, "lower" bound is enforced to be less than the second, "upper"
> bound.
>
> The problem is that with that restriction certain types of half-open
> intervals, namely those where the lower bound is the one being excluded,
> cannot be represented as a Range either currently or in Dave A's branch.
>
> On Tue, Apr 5, 2016 at 3:30 PM Howard Lovatt
>  wrote:
>
> I much prefer (0 ... -9).by(-1) and (0 ..< -10).by(-1)
>
> On Wednesday, 6 April 2016, Dave Abrahams via swift-evolution
>  wrote:
>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
>  wrote:
> >>
> >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> >>
> >>> [snip]
> >>>
> >>> Not included:
> >>> 1. I know Ranges are in flux, so I've held off on extending
> Range with
> >>> a striding(by:) method in this proof-of-concept.
> >>
> >> They're not in flux, except for not having been reviewed yet;
> they are
> >> settled in the swift-3-indexing-model branch.
> >
> > Did not know that. Will have to study what's there in more 
> detail.
> >
> >>> 2. No attempt at the suggested stride(from:to:steps:) quite 
> yet.
> >>
> >> #1 and #2 are mutually exclusive; we prefer #1 as it removes
> questions
> >> about the meaning of "to" or "through."
> >
> > I wasn't aware that was the thinking. Limiting strides to
> > `striding(by:)` removes the ability to express `stride(from: 0,
> to:
> > -10, by: -1)`
>
> IMO this:
>
> (-9...0).reverse()
>
> is better than
>
> stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -- 
> -- Howard.

-- 
Dave

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Ha, yes, clearly.

On Tue, Apr 5, 2016 at 4:00 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > Certainly, for integer literals and strides of -1.
> >
> > I meant more generally that removal of stride(...) will eliminate the
> > possibility of striding to but not through arbitrary half-open intervals
> (a, b],
> > where a < b, by a negative increment, because there is no such thing as
> `a>..b`
> > to express such an interval as a Swift range.
>
> That would clearly be
>
>  a<..b
>
> if it was needed, neh?
>
> >
> > Of course, all such cases can be handled by adjusting the endpoint and
> using a
> > closed range instead, but the same can be said for all half-open ranges.
> >
> > On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
> >  wrote:
> >
> > on Tue Apr 05 2016, Xiaodi Wu  wrote:
> >
> > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
> >  wrote:
> > >>
> > >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> > >>
> > >>> [snip]
> > >>>
> > >>> Not included:
> > >>> 1. I know Ranges are in flux, so I've held off on extending
> Range with
> > >>> a striding(by:) method in this proof-of-concept.
> > >>
> > >> They're not in flux, except for not having been reviewed yet;
> they are
> > >> settled in the swift-3-indexing-model branch.
> > >
> > > Did not know that. Will have to study what's there in more detail.
> > >
> > >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> > >>
> > >> #1 and #2 are mutually exclusive; we prefer #1 as it removes
> questions
> > >> about the meaning of "to" or "through."
> > >
> > > I wasn't aware that was the thinking. Limiting strides to
> > > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > > -10, by: -1)`
> >
> > IMO this:
> >
> > (-9...0).reverse()
> >
> > is better than
> >
> > stride(from: 0, to: -10, by: -1)
> >
> > What do you think?
> >
> > --
> > Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great
deal less readable than `stride(from: b, to: a, by: -s)`. And since the
latter is the status quo, I would say that it's a point against restricting
strides to the proposed syntax.

On Tue, Apr 5, 2016 at 3:57 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
> > Certainly, for integer literals and strides of -1.
> >
> > I meant more generally that removal of stride(...) will eliminate the
> > possibility of striding to but not through arbitrary half-open intervals
> (a, b],
> > where a < b, by a negative increment, because there is no such thing as
> `a>..b`
> > to express such an interval as a Swift range.
> > Of course, all such cases can be handled by adjusting the endpoint and
> using a
> > closed range instead
> >
>
> Indeed, if b - a is a multiple of s,
>
>(a+s...b).striding(by: s).reversed
>
> works.
>
> The question is whether this case is important enough to create a
> special family of functions for, and then deal with the naming issues
> raised by
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
> ?
>
> > On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
> >  wrote:
> >
> > on Tue Apr 05 2016, Xiaodi Wu  wrote:
> >
> > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
> >  wrote:
> > >>
> > >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> > >>
> > >>> [snip]
> > >>>
> > >>> Not included:
> > >>> 1. I know Ranges are in flux, so I've held off on extending
> Range with
> > >>> a striding(by:) method in this proof-of-concept.
> > >>
> > >> They're not in flux, except for not having been reviewed yet;
> they are
> > >> settled in the swift-3-indexing-model branch.
> > >
> > > Did not know that. Will have to study what's there in more detail.
> > >
> > >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> > >>
> > >> #1 and #2 are mutually exclusive; we prefer #1 as it removes
> questions
> > >> about the meaning of "to" or "through."
> > >
> > > I wasn't aware that was the thinking. Limiting strides to
> > > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > > -10, by: -1)`
> >
> > IMO this:
> >
> > (-9...0).reverse()
> >
> > is better than
> >
> > stride(from: 0, to: -10, by: -1)
> >
> > What do you think?
> >
> > --
> > Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Xiaodi Wu  wrote:

> Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great deal
> less readable than `stride(from: b, to: a, by: -s)`. And since the latter is 
> the
> status quo, I would say that it's a point against restricting strides to the
> proposed syntax.

Yes, those are all points.  But it totally avoids the question of
whether the case of striding over an inverted half-open range by a
negative step is an important enough case to be worth complicating the
library to make it readable.  

If it is important enough, I am much more inclined to support

(a<..b).striding(by: s).reversed

or

(a<..b).striding(by: -s)  // i.e., negative strides automatically reverse

simply because it makes a presumably-useful concept available (inverse
half-open range), re-uses existing syntax, and doesn't bring up these
naming questions.

Frankly, 

(a+s...b).striding(by: -s)

isn't all that bad.

> On Tue, Apr 5, 2016 at 3:57 PM Dave Abrahams via swift-evolution
>  wrote:
>
> on Tue Apr 05 2016, Xiaodi Wu
>  wrote:
>
> > Certainly, for integer literals and strides of -1.
> >
> > I meant more generally that removal of stride(...) will eliminate the
> > possibility of striding to but not through arbitrary half-open intervals
> (a, b],
> > where a < b, by a negative increment, because there is no such thing as
> `a>..b`
> > to express such an interval as a Swift range.
> > Of course, all such cases can be handled by adjusting the endpoint and
> using a
> > closed range instead
> >
>
> Indeed, if b - a is a multiple of s,
>
> (a+s...b).striding(by: s).reversed
>
> works.
>
> The question is whether this case is important enough to create a
> special family of functions for, and then deal with the naming issues
> raised by
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
>
> ?
>
> > On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
> >  wrote:
> >
> > on Tue Apr 05 2016, Xiaodi Wu  wrote:
> >
> > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
> >  wrote:
> > >>
> > >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
> > >>
> > >>> [snip]
> > >>>
> > >>> Not included:
> > >>> 1. I know Ranges are in flux, so I've held off on extending Range 
> with
> > >>> a striding(by:) method in this proof-of-concept.
> > >>
> > >> They're not in flux, except for not having been reviewed yet; they 
> are
> > >> settled in the swift-3-indexing-model branch.
> > >
> > > Did not know that. Will have to study what's there in more detail.
> > >
> > >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
> > >>
> > >> #1 and #2 are mutually exclusive; we prefer #1 as it removes 
> questions
> > >> about the meaning of "to" or "through."
> > >
> > > I wasn't aware that was the thinking. Limiting strides to
> > > `striding(by:)` removes the ability to express `stride(from: 0, to:
> > > -10, by: -1)`
> >
> > IMO this:
> >
> > (-9...0).reverse()
> >
> > is better than
> >
> > stride(from: 0, to: -10, by: -1)
> >
> > What do you think?
> >
> > --
> > Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

As the discussion seems to be quieting down, I've tried to summarize the 
on-list discussion and distill it into a preliminary proposal draft. Please let 
me know if this covers what you think it should or if I've entirely missed the 
mark. (It wouldn't be the first time.)

Regards,  -- Erica

Adding a #Self literal to Swift

Proposal: SE- 

Author(s): Erica Sadun 
Status: TBD
Review manager: TBD
 
Introduction

This proposal introduces #Self, a new literal that expands to self.dynamicType.

This proposal was discussed on the Swift Evolution list in the [Pitch] Adding a 
Self type name shortcut for static member access 
 
thread.

 
Motivation

It is common in Swift to reference an instance's type, whether for accessing a 
static member or passing a type for an unsafe bitcast, among other uses. At 
this time, you can either fully specify a type by name or use self.dynamicType 
to access an instance's dynamic runtime type as a value. 

struct MyStruct {
static func staticMethod() { ... }
func instanceMethod() {
MyStruct.staticMethod()
self.dynamicType.staticMethod()
}
}
As type names grow large, readability suffers, for example 
MyExtremelyLargeTypeName.staticMember
Code using hardwired type names is less portable than code that automatically 
knows its type.
Renaming a type means updating any TypeName references in code.
Using self.dynamicType fights against Swift's goals of concision and clarity; 
it is both noisy and esoteric.
self.dynamicType.classMember and TypeName.classMember may not be synonyms in 
class types with non-final members.
Joe Groff points out, Self inside a class scope already means "the dynamic 
class of 'self'", not "the type this declaration statically appears 
within...Swift ought to allow developers to utter Self in the bodies of class 
methods. It would be consistent to extend that courtesy to value types, where 
dynamic Self always matches the static type, from that principle"
 
Detail
 Design

In this proposal, #Self expands to the dynamic type of self and only the 
dynamic type of self. Joe Groff writes, "I don't think it's all that onerous to 
have to write ClassName.foo if that's really what you specifically mean."

 
Alternatives
 Considered

Not at this time

 
Acknowlegements

Thanks Sean Heber, Kevin Ballard, Joe Groff, Timothy Wood, Brent Royal-Gordon, 
Andrey Tarantsov, Austin Zheng___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 1:54 PM, Dave Abrahams  wrote:
> IMO this:
> 
>  (-9...0).reverse()
> 
> is better than 
> 
>  stride(from: 0, to: -10, by: -1)
> 
> What do you think?

The latter better reflects an author's actual intent. The former depends on 
implementation details, which can be hazy, especially, around the edge cases. 
It is quicker to read, understand, and verify that the latter is what is meant.

-- E

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Joe Groff via swift-evolution]

> On Apr 5, 2016, at 3:02 PM, Erica Sadun  wrote:
> 
> As the discussion seems to be quieting down, I've tried to summarize the 
> on-list discussion and distill it into a preliminary proposal draft. Please 
> let me know if this covers what you think it should or if I've entirely 
> missed the mark. (It wouldn't be the first time.)
> 
> Regards,  -- Erica
> 
> Adding a #Self literal to Swift
> 
>   • Proposal: SE-
>   • Author(s): Erica Sadun
>   • Status: TBD
>   • Review manager: TBD
> Introduction
> 
> This proposal introduces #Self, a new literal that expands to 
> self.dynamicType.
> 
> This proposal was discussed on the Swift Evolution list in the [Pitch] Adding 
> a Self type name shortcut for static member access thread.
> 
> Motivation
> 
> It is common in Swift to reference an instance's type, whether for accessing 
> a static member or passing a type for an unsafe bitcast, among other uses. At 
> this time, you can either fully specify a type by name or use 
> self.dynamicType to access an instance's dynamic runtime type as a value. 
> 
> struct MyStruct {
> static func staticMethod() { ... }
> func instanceMethod() {
> MyStruct.staticMethod()
> self.dynamicType.staticMethod()
> }
> }
> 
>   • As type names grow large, readability suffers, for example 
> MyExtremelyLargeTypeName.staticMember
>   • Code using hardwired type names is less portable than code that 
> automatically knows its type.
>   • Renaming a type means updating any TypeName references in code.
>   • Using self.dynamicType fights against Swift's goals of concision and 
> clarity; it is both noisy and esoteric.
>   • self.dynamicType.classMember and TypeName.classMember may not be 
> synonyms in class types with non-final members.
>   • Joe Groff points out, Self inside a class scope already means "the 
> dynamic class of 'self'", not "the type this declaration statically appears 
> within...Swift ought to allow developers to utter Self in the bodies of class 
> methods. It would be consistent to extend that courtesy to value types, where 
> dynamic Self always matches the static type, from that principle"
> Detail Design
> 
> In this proposal, #Self expands to the dynamic type of self and only the 
> dynamic type of self. Joe Groff writes, "I don't think it's all that onerous 
> to have to write ClassName.foo if that's really what you specifically mean."

What you're describing should be spelled `Self`, IMO. I think Tim intended 
`#Self` to mean the *static* type the code is declared inside (which is the 
same as Self unless you're in a class).

-Joe

> Alternatives Considered
> 
> Not at this time
> 
> Acknowlegements
> 
> Thanks Sean Heber, Kevin Ballard, Joe Groff, Timothy Wood, Brent 
> Royal-Gordon, Andrey Tarantsov, Austin Zheng

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

Updating. Gist here: 
https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227

-- E

> On Apr 5, 2016, at 4:04 PM, Joe Groff  wrote:
> 
>> 
>> On Apr 5, 2016, at 3:02 PM, Erica Sadun  wrote:
>> 
>> As the discussion seems to be quieting down, I've tried to summarize the 
>> on-list discussion and distill it into a preliminary proposal draft. Please 
>> let me know if this covers what you think it should or if I've entirely 
>> missed the mark. (It wouldn't be the first time.)
>> 
>> Regards,  -- Erica

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> What you're describing should be spelled `Self`, IMO. I think Tim intended 
> `#Self` to mean the *static* type the code is declared inside (which is the 
> same as Self unless you're in a class).

Yes, that is what I was aiming for. `#Self` would be a pretty much textual 
replacement just like #file, etc. That is, I could imaging it being used in a 
bunch of cases (not useful here, but just intending to enumerate the possible 
uses I see):

class Foo {
static let myClass: #Self.Type = #Self.self
static let anInstance: #Self = #Self()

static let defaultState = …

var state = #Self.defaultState  
}

The extra bit I was suggesting for allowing passing it in as a default argument 
like #file is for assert/precondition would be useful to me too:

func globalFunc(callerType: SomeType.Type = #Self.self, 
…)

which would only be callable inside a class/struct/enum context that conformed 
to SomeProtocol (unless you explicitly passed a callerType that met the 
requirements, of course). I’ve no idea if this latter bit is hard enough or 
controversial enough to be its own proposal =)

-tim

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Erica Sadun  wrote:

> On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>  wrote:
> IMO this:
>
> (-9...0).reverse()
>
> is better than 
>
> stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> The latter better reflects an author's actual intent. The former depends on
> implementation details, which can be hazy, especially, around the edge cases. 
> It
> is quicker to read, understand, and verify that the latter is what is
> meant.

Except that there seems to be some confusion over what "to:" means, right?

-- 
Dave

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 4:17 PM, Timothy Wood  wrote:
> 
> 
>> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> What you're describing should be spelled `Self`, IMO. I think Tim intended 
>> `#Self` to mean the *static* type the code is declared inside (which is the 
>> same as Self unless you're in a class).
> 
> Yes, that is what I was aiming for. `#Self` would be a pretty much textual 
> replacement just like #file, etc. That is, I could imaging it being used in a 
> bunch of cases (not useful here, but just intending to enumerate the possible 
> uses I see):

Please check to ensure that the changes I just made match your expectations:

https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 


-- E


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

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Apr 05 2016, Erica Sadun  wrote:
> 
>>On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>> wrote:
>>IMO this:
>> 
>>(-9...0).reverse()
>> 
>>is better than 
>> 
>>stride(from: 0, to: -10, by: -1)
>> 
>>What do you think?
>> 
>> The latter better reflects an author's actual intent. The former depends on
>> implementation details, which can be hazy, especially, around the edge 
>> cases. It
>> is quicker to read, understand, and verify that the latter is what is
>> meant.
> 
> Except that there seems to be some confusion over what "to:" means, right?


obviously (0..<-10).by(-2) would be best.

-- E

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 4:22 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Tue Apr 05 2016, Erica Sadun  wrote:
>> 
>>>   On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>>>wrote:
>>>   IMO this:
>>> 
>>>   (-9...0).reverse()
>>> 
>>>   is better than 
>>> 
>>>   stride(from: 0, to: -10, by: -1)
>>> 
>>>   What do you think?
>>> 
>>> The latter better reflects an author's actual intent. The former depends on
>>> implementation details, which can be hazy, especially, around the edge 
>>> cases. It
>>> is quicker to read, understand, and verify that the latter is what is
>>> meant.
>> 
>> Except that there seems to be some confusion over what "to:" means, right?
> 
> 
> obviously (0..<-10).by(-2) would be best.
> 
> -- E

or even (0..<(-10)).by(-2)

As much as this looks like a Lisp program, it still improves over the 
alternatives

-- E



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

Re: [swift-evolution] Feature proposal: Range operator with step

[Stephen Canon via swift-evolution]

> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Tue Apr 05 2016, Erica Sadun  wrote:
>> 
>>>   On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>>>wrote:
>>>   IMO this:
>>> 
>>>   (-9...0).reverse()
>>> 
>>>   is better than 
>>> 
>>>   stride(from: 0, to: -10, by: -1)
>>> 
>>>   What do you think?
>>> 
>>> The latter better reflects an author's actual intent. The former depends on
>>> implementation details, which can be hazy, especially, around the edge 
>>> cases. It
>>> is quicker to read, understand, and verify that the latter is what is
>>> meant.
>> 
>> Except that there seems to be some confusion over what "to:" means, right?
> 
> obviously (0..<-10).by(-2) would be best.

(0 ..> -10).by(-2)?

Maybe having another range operator is overkill, but ..< seems pretty bonkers 
here.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Well, probably best to have another operator: 0..>(-10). We go from 0 to
greater than -10.
On Tue, Apr 5, 2016 at 5:22 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Tue Apr 05 2016, Erica Sadun  wrote:
> >
> >>On Apr 5, 2016, at 1:54 PM, Dave Abrahams
> >> wrote:
> >>IMO this:
> >>
> >>(-9...0).reverse()
> >>
> >>is better than
> >>
> >>stride(from: 0, to: -10, by: -1)
> >>
> >>What do you think?
> >>
> >> The latter better reflects an author's actual intent. The former
> depends on
> >> implementation details, which can be hazy, especially, around the edge
> cases. It
> >> is quicker to read, understand, and verify that the latter is what is
> >> meant.
> >
> > Except that there seems to be some confusion over what "to:" means,
> right?
>
>
> obviously (0..<-10).by(-2) would be best.
>
> -- E
>
> ___
> 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] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Xiaodi Wu  wrote:

> On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams  wrote:
>>
>> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>>
>>> [snip]
>>>
>>> Not included:
>>> 1. I know Ranges are in flux, so I've held off on extending Range with
>>> a striding(by:) method in this proof-of-concept.
>>
>> They're not in flux, except for not having been reviewed yet; they are
>> settled in the swift-3-indexing-model branch.
>
> Did not know that. Will have to study what's there in more detail.

Actually, let me amend that.  The protocols involved need to be
de-underscored, the doc comments need to be written, and I am noticing a
few missing things around the edges.  But the basic shape of it is stable.

>
>
>>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>>
>> #1 and #2 are mutually exclusive; we prefer #1 as it removes questions
>> about the meaning of "to" or "through."
>
> I wasn't aware that was the thinking. Limiting strides to
> `striding(by:)` removes the ability to express `stride(from: 0, to:
> -10, by: -1)` because Range enforces (and it looks like it will
> continue to do so in the swift-3-indexing-model branch?) `lowerBound
> <= upperBound`, and in a half-open range it's the upper bound that's
> excluded.
>
>>> 2. No tests written yet for this proof-of-concept; I noticed that
>>> there's a stub for testing strides with bounds of type Double, but
>>> there's a comment about things not being ready because Double conforms
>>> to RandomIndexType--not sure what to make of that.
>>
>> Comments in that branch are badly out-of-date.  It's worth trying that,
>> especially since there is no RandomAccessIndexType in that branch any
>> longer.
>>
>>> 3. Haven't gotten around to testing performance.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 5, 2016, at 3:21 PM, Erica Sadun  wrote:
> 
> Please check to ensure that the changes I just made match your expectations:
> 
> https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 
> 
That looks good to me — thanks Erica!

-tim

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 4:24 PM, Stephen Canon  wrote:
> 
>> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> on Tue Apr 05 2016, Erica Sadun >> > wrote:
>>> 
   On Apr 5, 2016, at 1:54 PM, Dave Abrahams
   mailto:dabrah...@apple.com>> wrote:
   IMO this:
 
   (-9...0).reverse()
 
   is better than 
 
   stride(from: 0, to: -10, by: -1)
 
   What do you think?
 
 The latter better reflects an author's actual intent. The former depends on
 implementation details, which can be hazy, especially, around the edge 
 cases. It
 is quicker to read, understand, and verify that the latter is what is
 meant.
>>> 
>>> Except that there seems to be some confusion over what "to:" means, right?
>> 
>> obviously (0..<-10).by(-2) would be best.
> 
> (0 ..> -10).by(-2)?
> 
> Maybe having another range operator is overkill, but ..< seems pretty bonkers 
> here.

Suddenly SE-0051 is starting to look a lot more promising.

https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
 


-- E

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

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 5, 2016, at 12:06 PM, Douglas Gregor  wrote:
> 
> I would not want this to be implicit behavior: it should be recorded in the 
> source with, e.g.,
> 
>   @availability(iOS: 9.3) import YourCustomFramework
> 
> so that it is clear that the imported declarations are only available on iOS 
> 9.3 or newer.
> 
>   - Doug

Would you promote using this syntax for the Apple frameworks as well?

A major goal for me is syntax consistency between Apple's and third-party 
frameworks.  That way the knowledge of how to use one transfers to the other, 
and we ensure people with fresh ideas about how to build frameworks are not 
burdened with educating application developers about "novel" import syntax.

>From consulting the table 
>,
> developers with a DT of 7.0 (which is the oldest Swift supports) would need 
>to add e.g. @availability(iOS 8.0, *) import CloudKit for a few frameworks, 
>but that seems like a pretty easy change.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Stephen Canon  wrote:

> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution
>  wrote:
>
> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Tue Apr 05 2016, Erica Sadun
>  wrote:
>
> On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>  wrote:
> IMO this:
>
> (-9...0).reverse()
>
> is better than 
>
> stride(from: 0, to: -10, by: -1)
>
> What do you think?
>
> The latter better reflects an author's actual intent. The former
> depends on
> implementation details, which can be hazy, especially, around the
> edge cases. It
> is quicker to read, understand, and verify that the latter is what
> is
> meant.
>
> Except that there seems to be some confusion over what "to:" means,
> right?
>
> obviously (0..<-10).by(-2) would be best.
>
> (0 ..> -10).by(-2)?
>
> Maybe having another range operator is overkill, but ..< seems pretty bonkers
> here.

I can't see any excuse for putting the smaller number on the right.  If
one really needs the numbers in that order, then I agree a stride free
function is better.

-- 
Dave

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Tue Apr 05 2016, Erica Sadun  wrote:

>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Tue Apr 05 2016, Erica Sadun  wrote:
>> 
>
>>>On Apr 5, 2016, at 1:54 PM, Dave Abrahams
>>> wrote:
>>>IMO this:
>>> 
>>>(-9...0).reverse()
>>> 
>>>is better than 
>>> 
>>>stride(from: 0, to: -10, by: -1)
>>> 
>>>What do you think?
>>> 
>>> The latter better reflects an author's actual intent. The former depends on
>>> implementation details, which can be hazy, especially, around the edge 
>>> cases. It
>>> is quicker to read, understand, and verify that the latter is what is
>>> meant.
>> 
>> Except that there seems to be some confusion over what "to:" means, right?
>
> obviously (0..<-10).by(-2) would be best.

I don't think that's obvious at all, because 0 ≮ 10

-- 
Dave

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

[swift-evolution] Notes from Swift core team 2016-04-05 design discussion

[Alex Martini via swift-evolution]

To help keep proposals moving forward, the Swift core team has set aside some 
time specifically for design discussions of upcoming proposals.  Below are some 
rough notes from the yesterday's discussion.

These are informal comments, intended to guide the proposals in directions that 
draw constructive feedback. You are welcome to ignore the feedback, agree with 
it, or disagree with it.  As always, the formal decision doesn't happen until 
after the review period ends.




SE-0058: Allow Swift types to provide custom Objective-C representations 

https://github.com/apple/swift-evolution/0058-objectivecbridgeable.md 

This is essentially cleaning up the existing underscored protocol and blessing 
it as the way to bridge Obj-C types over to Swift value types. Mechanically, 
all the work is essentially done in the underscored version.

There are some C++ interop hacks to make things handle in-out. Calling the 
initializers from the C++ part of the runtime is really hairy; we use the 
extension’s function versions that use in-out instead.

There is a “Swift indirect result” attribute that we can use for pointers like 
this. It’s in Clang — this is what you do if you want to directly call Swift 
code. We should be able to do this with John’s changes.

There’s a level of hackiness here, but it’s part of the standard library, so we 
expect we can keep it working. If we had more generalized existentials, that 
C++ could move into Swift code. Or we could write it in SIL.

Question on the list about defining both the bridged type and the value type in 
Swift. The bridging gets interesting when you export back to Objective-C. We 
could make it work both ways — we’re probably close to getting it to work — 
it’s a matter of making sure we find the value type and re-import the generated 
header. We have to make sure that when you see the Obj-C version of the Swift 
type come in again via Clang, that you know it’s already wired up.

We have some C bridging around Darwin, but it’s very ad-hoc right now. Right 
now, the dynamic cast machinery in all three places that implement it only have 
to care about class and struct types, but it’s unfortunate to have this. There 
are class-to-class bridging because of error types: you can throw an instance 
of a class. It’s a little different because you’re not turning the Swift error 
type as NSError to Obj-C, although it has been proposed that we should bridge 
between ErrorProtocol and NSError.

To prove that something fails, you’re always doing this work. On the other 
hand, it’s a dynamic cast, so we don’t expect it to be fast. Making 
value-to-value casting require protocol lookup would be unfortunate.

There are a lot of people who want to do things like hiding members. Doing that 
via API notes seems much preferred over bridging it to another C type.

You might want to do something like this around sockaddr types that use pointer 
punning, mapping them to the Swift idiom of protocols. But the most common 
thing people want to do is take advantage of Swift-only features but still 
projects out to Objective-C in a way that makes sense.

There are some objective-C specific hacks such as the optional parameter in 
init(unconditionallyBridgedFromObjectiveC:) which handles the case of returning 
nilfrom a method that said it wouldn’t return nil. The contract of treating nil 
and the empty collection as the same makes sense. This hack supports it. A 
general C bridging protocol might be a little different.

We have C bridged types, such as bool, where C has a type with the same meaning 
but a memory layout that’s not compatible.

There are some APIs in there that could have better names. In the argument 
labels, the ‘-ed’ should probably be ‘-ing’.

The main difference from the underscored version is the removal of underscores 
and using an initializer instead of a static method.

Do we want a standard shorthand for these long names in the mangler?







Side-car annotations of C libraries (i.e., API notes as a first-class feature) 

API notes is some YAML input that lets you add certain kinds of attributes to 
Clang declarations. We created it for specific problems, but it is more 
generally useful. It seems totally reasonable that some package could wrap an 
existing C library via sidecar data and provide a more Swift idiomatic 
interface to it.

For example, dyspatch_async() turns into a member named async(_:) on a class 
named OS_dispatch_queue. You can form properties like how 
dispatch_get_main_queue() maps over. This lets the overlay for that API stay 
small.

The major downside of API notes is that it’s a limited format with a baroque 
implementation; every time we want to add an attribute, we have to update the 
YAML parser and then Clang and then the serialized form of the API notes. For 
this to be a “real thing” we should intentionally design the format. A simple 
text-based format is great, but th

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution 
>  wrote:
> I don't think that's obvious at all, because 0 ≮ 10

Points brought up elsewhere:

* A range does not have direction, it is is an area of variation between lower 
and upper limits.
* A range does not go from a larger amount to a smaller amount because it is 
not a sequence
* Much of this problem goes away with striding (as Dave pointed out several 
times, sorry Dave)

After consideration, I have been persuaded to the opinion that

>  stride(from: 0, to: -10, by: -1)

and 

>(-9...0).reverse()

both represent the numbers -9, -8,...,0 better than any alternatives I have 
offered. I still
prefer the stride version for intent and clarity.

That said, I also prefer my revised SE-0051 semantics for better representing 
what strides will
attempt to do.

-- Erica
p.s. Thanks all for the patient explanations




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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

I think my opinion is largely the same. A range is not a stride, and
sometimes we have use for striding backwards, a use case that shouldn't be
penalized. +1 to the free function.

I wouldn't mind, orthogonally, a way to express (a, b] as a range. It just
seems like that should be of use, somewhere.

Finally, orthogonal to all of the above, I'm super eager to end error
accumulation in floating point strides.
On Tue, Apr 5, 2016 at 6:52 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> I don't think that's obvious at all, because 0 ≮ 10
>
>
> Points brought up elsewhere:
>
> * A range does not have direction, it is is an area of variation between
> lower and upper limits.
> * A range does not go from a larger amount to a smaller amount because it
> is not a sequence
> * Much of this problem goes away with striding (as Dave pointed out
> several times, sorry Dave)
>
> After consideration, I have been persuaded to the opinion that
>
>  stride(from: 0, to: -10, by: -1)
>
>
> and
>
>(-9...0).reverse()
>
>
> both represent the numbers -9, -8,...,0 better than any alternatives I
> have offered. I still
> prefer the stride version for intent and clarity.
>
> That said, I also prefer my revised SE-0051 semantics for better
> representing what strides will
> attempt to do.
>
> -- Erica
> p.s. Thanks all for the patient explanations
>
>
>
>
> ___
> 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] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

On Tue, Apr 5, 2016 at 4:28 PM, Dave Abrahams via swift-evolution
 wrote:
>
> on Tue Apr 05 2016, Xiaodi Wu  wrote:
>
>> Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great 
>> deal
>> less readable than `stride(from: b, to: a, by: -s)`. And since the latter is 
>> the
>> status quo, I would say that it's a point against restricting strides to the
>> proposed syntax.
>
> Yes, those are all points.  But it totally avoids the question of
> whether the case of striding over an inverted half-open range by a
> negative step is an important enough case to be worth complicating the
> library to make it readable.

At the risk of tedious pedantry--

Given that this discussion was spawned from one about Swift's for
loop, it would be remiss not to circle back and point out that what's
at issue isn't a matter of complicating an existing implementation to
support stride to (or, striding over an inverted half-open range) with
negative stride size, but rather whether a proposed simplification
ought to be implemented that removes this already supported use case.
IMO, the existing implementation is not overly inelegant, and deep in
the logic of StrideToIterator is an if statement (using a ternary
operator in the expression, no less!) to account for negative stride
size--so I can only conclude that its being supported isn't merely a
happy byproduct of the current implementation but very much an
explicitly planned-for feature.

> If it is important enough, I am much more inclined to support
>
> (a<..b).striding(by: s).reversed
>
> or
>
> (a<..b).striding(by: -s)  // i.e., negative strides automatically reverse
>
> simply because it makes a presumably-useful concept available (inverse
> half-open range), re-uses existing syntax, and doesn't bring up these
> naming questions.
>
> Frankly,
>
> (a+s...b).striding(by: -s)
>
> isn't all that bad.
>
>> On Tue, Apr 5, 2016 at 3:57 PM Dave Abrahams via swift-evolution
>>  wrote:
>>
>> on Tue Apr 05 2016, Xiaodi Wu
>>  wrote:
>>
>> > Certainly, for integer literals and strides of -1.
>> >
>> > I meant more generally that removal of stride(...) will eliminate the
>> > possibility of striding to but not through arbitrary half-open 
>> intervals
>> (a, b],
>> > where a < b, by a negative increment, because there is no such thing as
>> `a>..b`
>> > to express such an interval as a Swift range.
>> > Of course, all such cases can be handled by adjusting the endpoint and
>> using a
>> > closed range instead
>> >
>>
>> Indeed, if b - a is a multiple of s,
>>
>> (a+s...b).striding(by: s).reversed
>>
>> works.
>>
>> The question is whether this case is important enough to create a
>> special family of functions for, and then deal with the naming issues
>> raised by
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
>>
>> ?
>>
>> > On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams
>> >  wrote:
>> >
>> > on Tue Apr 05 2016, Xiaodi Wu  wrote:
>> >
>> > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams
>> >  wrote:
>> > >>
>> > >> on Sat Apr 02 2016, Xiaodi Wu  wrote:
>> > >>
>> > >>> [snip]
>> > >>>
>> > >>> Not included:
>> > >>> 1. I know Ranges are in flux, so I've held off on extending Range 
>> with
>> > >>> a striding(by:) method in this proof-of-concept.
>> > >>
>> > >> They're not in flux, except for not having been reviewed yet; they 
>> are
>> > >> settled in the swift-3-indexing-model branch.
>> > >
>> > > Did not know that. Will have to study what's there in more detail.
>> > >
>> > >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet.
>> > >>
>> > >> #1 and #2 are mutually exclusive; we prefer #1 as it removes 
>> questions
>> > >> about the meaning of "to" or "through."
>> > >
>> > > I wasn't aware that was the thinking. Limiting strides to
>> > > `striding(by:)` removes the ability to express `stride(from: 0, to:
>> > > -10, by: -1)`
>> >
>> > IMO this:
>> >
>> > (-9...0).reverse()
>> >
>> > is better than
>> >
>> > stride(from: 0, to: -10, by: -1)
>> >
>> > What do you think?
>> >
>> > --
>> > Dave
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> __

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Kevin Lundberg via swift-evolution]

Generally I'm +1 on this, but I do have a concern. It's not made
explicit in the proposal, but I presume that this is meant to only be
available on Darwin, and not Linux or other platforms that don't have
swift using the Objective-C runtime? (Please correct me if I am mistaken.)

I ask because of the swift-corelibs-foundation project; Presumably once
that is complete for Swift 3, code that makes use of this type bridging
should be able to be run cross-platform. For example:

var a = [AnyObject]()
(a as NSArray).addObject(NSObject()) // should this work on all platforms?

swift-corelibs-foundation uses its own protocol named
_ObjectTypeBridgeable (defined here:
https://github.com/apple/swift-corelibs-foundation/blob/338f4bf3a89c75a0420b49f5701466e106af02b5/Foundation/NSSwiftRuntime.swift#L205)
to simulate what happens today on Darwin platforms, but there is no
language support for it so API consumers must explicitly call its
bridging methods. It would be great if corelibs-foundation (and any code
designed to work on Linux) could take advantage of this proposal to
provide the language support, and if the proposal as written is not
intended to have an effect on Linux at all, then I would suggest we
modify it so that the resulting implementation is not tied to
Objective-C and Darwin only.

-Kevin

On 4/4/2016 1:44 PM, Joe Groff via swift-evolution wrote:
> Hello Swift community,
>
> The review of “Allow Swift types to provide custom Objective-C
> representations” begins now and runs through April 11, 2016. The
> proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at
> the top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reply text
>
> Other replies
>
> *What goes into a review?*
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the
> direction of Swift. When writing your review, here are some questions
> you might want to answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a
> change to Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Joe
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Brent Royal-Gordon via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md

>But then, these *are* intended to be full-width type conversions,
>are they not?  Why not these:
> 
>  init?(_ source: ObjectiveCType)
>  init(_ source: ObjectiveCType?)
> 
>?  If any of these transformations are wrong, it would good to have
>a rationale as to why.

I really don't like these two differing only by the optionality of their 
argument and return type, especially if they're going to have *no* argument 
label, which will make them look very attractive. And the unconditional one has 
many strange semantics—the extra layer of optionality on the argument, the fact 
that it may *lazily* crash if you access a sub-object which isn't permitted, 
etc. So I would at least label that one:

init?(_ source: ObjectiveCType)
init(forced source: ObjectiveCType?)

I'm also a little worried about having an `init?(_:)` when a particular 
conversion might reasonably always succeed. The lack of a label will imply to 
users that this is something they can use directly; 

> 3. Is this proposal introducing a backdoor people can exploit to create
>   user-defined implicit conversions?  If so, shouldn't that worry us?

This proposal reads to me like it permits conversions by casting, but not by 
simply using one type where another belongs.

> 4. This proposal should probably support creating a type that only
>   bridges *from* Objective-C, to handle bridging mutable Objective-C
>   classes without an immutable base class to value types (anything else
>   breaks one of the languages' expectations of value or reference
>   semantics).  This suggests a hierarchy of two protocols might be
>   warranted.

I agree.

Here's an alternative design. It does a few things:

* Splits bridging from and bridging to Objective-C so they can be applied 
independently.
* Splits conditional and unconditional bridging from Objective-C. 
* Explicitly marks Objective-C types with their Swift equivalents, even in 
Swift, to make it clear that each Objective-C type bridges to exactly one Swift 
type, and which type that is. (This allows you to have multiple conversions 
between various Swift types and a single Objective-C type, while explicitly 
specifying which one, if any, should be used when translating Objective-C APIs 
to Swift.)

I'm using the proposed SE-0041 protocol naming conventions 
(https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md)
 to name the protocols. I'm also assuming the presence of conditional 
conformances and where clauses on associated types; these protocols would have 
to be temporarily hobbled to work within the type system's current capabilities.

/// Conforming types can be cast from Self to ObjectiveCType using `as` 
(or a subtype using `as?` 
/// or `as!`), and Swift APIs taking or returning Self are exposed to 
Objective-C as ObjectiveCType.
protocol ObjectiveCRepresentable {
associatedtype ObjectiveCType: AnyObject
func bridged() -> ObjectiveCType
}

/// Conforming types can be cast from ObjectiveCType or a subtype to 
Self using `as?` or `as!`.
/// 
/// -SeeAlso: ObjectiveCUnconditionallyCreatable, ObjectiveCBridgeable
protocol ObjectiveCCreatable {
associatedtype ObjectiveCType: AnyObject
init?(_ source: ObjectiveCType)
init(forced source: ObjectiveCType?)
}

/// Conforming types can be cast from UnconditionalObjectiveCType to 
Self using `as`.
/// 
/// -Note:  A type can conform to both this protocol and 
ObjectiveCCreatable to 
/// allow both an unconditional exact cast and a 
conditional inexact one. 
/// For instance, Array can have ObjectiveCType = 
NSArray 
/// and UnconditionalObjectiveCType = NSArray.
protocol ObjectiveCUnconditionallyCreatable {
associatedtype UnconditionalObjectiveCType: AnyObject
init(_ source: UnconditionalObjectiveCType?)
}

/// Conforming types are translated from Self to SwiftType in APIs 
imported from Objective-C.
/// 
/// -Note:  Objective-C headers can apply this protocol to their 
classes using the
/// SWIFT_BRIDGED("SwiftType") attribute.
/// -Remark: This could instead be indicated with a Swift-side 
attribute.
protocol ObjectiveCBridgeable: class {
associatedtype SwiftType: ObjectiveCUnconditionallyCreatable 
where SwiftType.UnconditionalObjectiveCType == Self
}

Interestingly, another alternative would be to remove the bridging semantic 
from ObjectiveCRepresentable and put it in a subprotocol:

/// Conforming types can be cast from Self to ObjectiveCType using `as` 
(or a subtype usin

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Brent Royal-Gordon via swift-evolution]

(Sorry, sent without finishing a sentence.)

>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
> 
>>   But then, these *are* intended to be full-width type conversions,
>>   are they not?  Why not these:
>> 
>> init?(_ source: ObjectiveCType)
>> init(_ source: ObjectiveCType?)
>> 
>>   ?  If any of these transformations are wrong, it would good to have
>>   a rationale as to why.
> 
> I really don't like these two differing only by the optionality of their 
> argument and return type, especially if they're going to have *no* argument 
> label, which will make them look very attractive. And the unconditional one 
> has many strange semantics—the extra layer of optionality on the argument, 
> the fact that it may *lazily* crash if you access a sub-object which isn't 
> permitted, etc. So I would at least label that one:
> 
>   init?(_ source: ObjectiveCType)
>   init(forced source: ObjectiveCType?)
> 
> I'm also a little worried about having an `init?(_:)` when a particular 
> conversion might reasonably always succeed. The lack of a label will imply to 
> users that this is something they can use directly; 

if the conversion always succeeds, though, it will unnecessarily be returning 
an optional value. (And from what I can tell, you can't satisfy an optional 
return value in a protocol with a member having a non-optional return value. 
Not sure why that is.)

-- 
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-0056: Allow trailing closures in `guard` conditions

[Dany St-Amant via swift-evolution]

Yet another inconsistency in this area (for people who care about them)

While the 'while {}' does not support trailing closures, the 'repeat {} while' 
does support them. So, will the folks against supporting them in 'guard' ask 
for a change to drop the support in the 'repeat {} while'?

Dany

> Le 4 avr. 2016 à 19:52, Dany St-Amant via swift-evolution 
>  a écrit :
> 
> 
>> Le 4 avr. 2016 à 10:19, Patrick Gili  a écrit :
>> 
>> If I understand you correctly, you think adding keywords represents an 
>> inconsistency.
> 
> I didn't write that, maybe I should have put my reply between your two 
> paragraphs. Adding keywords such as 'then' and 'do' could add some 
> consistency, but another word than 'do' will likely have to be found as 'do' 
> could break code as highlighted by Xiaodi, as well as cause by the 'catch' 
> case caught by Jeremy.
> 
> I was merely highlighting the current inconsistency of the variable scope of 
> 'guard let' versus 'if let' which no one had mentioned so far... An 
> inconsistency which is (logically) fully design intent and will remain 
> forever. So some inconsistencies are acceptable, 
> 
> Is accepting trailing closure in 'guard' really a new inconsistency?
> Being unable to use them with 'guard', 'if', 'switch' is the original 
> inconsistency as the trailing closure seemed to be use in many places 
> (including argument list of another function). Adding 'guard' as a location 
> where trailing closure are allowed doesn't really introduce a new 
> inconsistency, it just incompletely reduce an existing inconsistency.
> 
>> However, I think it would add considerable consistency and utility to the 
>> Swift language. Yes, it would make it inconsistent with the generations of 
>> C-like languages that have come before it. However, I think we've already 
>> taken considerable steps from away from C-like languages; for example, 
>> removing C-like for-loop syntax and unary increment/decrement operators.
> 
> I am with you here, Swift is Swift, C is C, Swift should not be hampered by 
> keeping the syntax identical to C. But, it seems that most prefer to type 
> less, so we should be really careful with proposing new keywords like this 
> 'then' and 'do' as they carry little meaning,  have to be mandatory (as per 
> Chris), and are really needed only for trailing closure which will not be 
> used by everyone.
> 
> So, I'm against adding these 'then' and 'do' keywords for the sake of 
> providing the trailing support to 'if' and 'for'. And I do not see why we 
> should prevent 'guard' from gaining this support just because the 'if' and 
> 'for' doesn't also have it.
> 
> Dany
>  
>> 
>>> On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution 
>>>  a écrit :
>>> 
> What is your evaluation of the proposal?
 I think there is a lot of value to allowing trailing closures in the guard 
 condition clause. However, not at the cost of inconsistency. We have 
 reviewed many proposals over the last month that addressed consistency 
 issues in the Swift language, and if I'm not mistaken, all of them have 
 been accepted by the community, larger to eliminate the inconsistency.
 
 Because of this, I think two of the alternatives stated by the proposal 
 have credibility:
 1) Eliminate the "else" keyword from the guard syntax.
 2) Add keywords to "if", "while", "for", and "switch" to delineate the 
 condition clause from the body of the statement.
 
 The second alternative has more appeal, because it supports trailing 
 closures without "heroics".
>>> 
>>> It have been mentioned multiple times that allowing trailing closure only 
>>> for guard is creating an inconsistency, but these keywords already are 
>>> inconsistent with the each other (beside the presence of the 'trailing' 
>>> else keyword) on the variable scoping:
>>> 
>>> - guard let: outer scope immutable variable
>>> - if let: inner scope immutable variable
>>> - for: inner scope immutable variable without let keyword
>>> 
>>> Consistency is good, but since each keywords are not for the exact same 
>>> thing, it is normal to see some variances.  Like the global scope of the 
>>> immutable variable created by guard; as per the intent of the keyword, or 
>>> its trailing else keyword; needed to clarify that what follow is for, for 
>>> lack of better word, the 'else' case.
>>> 
>>> So as long as such inconsistency have a "raison d'être", that they have 
>>> been designed and are not an oversight; there should be no reason to not 
>>> allow them.
>>> 
>>> Dany
>>> 
 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
 No.
 
> Does this proposal fit well with the feel and direction of Swift?
 No. Please don't add inconsistencies to the language, as we're just going 
 to have to deal with it down the road.
 
> If you h

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

[Brent Royal-Gordon via swift-evolution]

> Types associated with a protocol are not namespaced by the protocol, but 
> rather by the protocol's adopters. As such, when two protocols declare a 
> common associatedType, adoption of those protocols introduces undesirable 
> ambiguity.

I don't think there's much of a point solving this just for associated types. 
The same issue exists for all protocol requirements.

> Given the understandable propensity of developers to arrive at similarly 
> named types (T, for example), it is likely that this problem will reduce the 
> compatibility of packages for reasons that may not be entirely clear to the 
> package consumer.

Then don't do that. Absurdly short associated/generic type names are like 
absurdly short variable or function names—they're okay in a very small context 
like a short function or a single loop, but a bad idea in a wider context. 
That's why the Swift 2 standard library moved away from using short names like 
`T` in generic types like Array and Optional.

-- 
Brent Royal-Gordon
Architechies

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