Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Martin Waitz via swift-evolution]

Hi Boris,

> Am 31.01.2017 um 03:48 schrieb Rick Ballard :
> 
>> 
>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>> > wrote:
>> 
>> OK, you are right, branches can be helpful to have in the manifest.
>> But I’m still confident that we must not put explicit version information 
>> into it.
>> They belongs into the `Package.pins` file.
>> That is enough to get reproducible builds.
> 
> By "explicit version information", do you mean that you shouldn't put a git 
> revision hash in the manifest – only branches and version tags should be 
> acceptable?

yes exactly.
BTW: the more I think about it, the more I like the possibility to specify a 
branch in the manifest.

> I'd agree that the revision-based initializer is a marginal feature; normally 
> your package should depend on a version range or is tracking a branch. That 
> said, we can imagine that you might wind up needing to peg your dependency to 
> a specific revision that isn't a version tag, and not track a moving branch, 
> so this seemed like a fairly harmless feature to add for that case. What is 
> your objection about supporting that?
> 
> The decision about whether to put this information in your pins or in your 
> manifest should be driven by whether it's something your package requires, or 
> is just a workflow choice. If you just want to temporarily stick to a 
> specific revision of your dependency for workflow reasons, pinning is the 
> right way to do that. If, however, your package currently requires that 
> revision, and isn't going to work properly without it, then the manifest is 
> the right way to express that. You'd want that specification to stick even if 
> someone did `swift package update --repin` to get newer pinned revisions.

Well, I guess your package will also work with all commits following your 
special one.
Then I’d be enough to specify the branch: your special dependency version is 
already specified in the pins file and `swift package update` will only update 
to newer revisions.

So why would you (temporarily) want to stick to a specific version?
Because it happens to be the only compatible one at that time.
So even that is a workflow thing and not a „this is the one and only“.
And if you really really need to choose a specific commit which is in the past, 
then you can always create a special branch just for it.

I really like to have a clear separation between manifest and the pins file.
Otherwise I fear that inexperienced maintainers hard-code their dependencies to 
a specific version by accident.
I've seen too strict version specifications too often already (e.g. on npm) ;-)

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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[David Hart via swift-evolution]

> On 31 Jan 2017, at 01:59, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 11:42 AM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> The reason Swift works like this is because you can assign a function value 
>> (independently of calling it) to a variable. So there aren't two separate 
>> namespaces separating function names and variable names.
> 
> To be honest, I would say that there's no "reason" for this, except as 
> lingering effects of our early "functions have simple names, and arguments 
> have labeled tuple type" model. If we had originally implemented the language 
> with its current (at least aspirational) Smalltalk-ish compound-names model, 
> we probably would have ended up allowing this, since the var and func do 
> formally have different names. The ability to reference a function by only 
> the first segment of its name is likewise legacy of the original model, 
> though it happens to be useful since good naming hygiene encourages different 
> base names for different things to begin with.

Is there a reason we couldn't push a proposal forward to have the compiler 
prefer function identifiers when the identifier is followed by a function call 
syntax? It would be a breaking change, but I'd wager it'd be quite rare: at 
least rarer than the amount of times this problem has bitten me since Swift 3's 
grand renaming, forcing me to `self.` prefix the function call (when I can and 
it's an instance function).

> -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] Warn about unused Optional.some(())

[David Hart via swift-evolution]

> On 31 Jan 2017, at 07:23, Daniel Duan via swift-evolution 
>  wrote:
> 
> I guess I missed that discussion. This "feature" does more harm than good 
> IMHO.

Indeed. I find this behavior very surprising and goes against Swift's 
safe-by-default and explicitness philosophy.

I'd argue removing it.

>> On Jan 30, 2017, at 10:16 PM, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 31, 2017, at 1:03 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution 
  wrote:
 
 
> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Right now, expressions that evaluates to Optional<()>, 
> Optional>… gets special treatment when it’s unused. For 
> example:
> 
> func f(s: String) {}
> let s: String = “”
> s.map(f) // no warning here, even tho the resulting type is 
> `Optional<()>` and unused.
> 
> func g() throws {}
> try? g() // no warnings here neither.
> 
> This is convenient, but encourages composing map/filter/reduce, etc with 
> side-effect-ful functions, which we have found a few cases of in our 
> production code recently. Granted, these cases could’ve been caught with 
> more careful code reviews. But we wouldn’t have missed them if this 
> “feature” didn’t exist.
> 
> I think we should remove the special treatment so that code in the 
> example above would generate a warning about `()?` being unused. Users 
> can silence it manually by assigning the result to `_`. 
> 
> OTOH, this would undermine the convenience of `try?` when the throwing 
> function don’t return anything.
 
 IMHO, using ‘try?’ to ignore an error result, instead of just turning it 
 into an optional, is an anti-pattern, and forcing users to write ‘_ = try? 
 foo()’ might not be so bad…
>>> 
>>> +1
>> 
>> Isn't this how it was in Swift 2.x and the first versions of 3.0? I believe 
>> this was changed only recently - which I personally found as good news. In 
>> some cases you simply do not care about the error result since it has no 
>> impact if the call fails and typing "_ =" seemed like boilerplate...
>> 
>> If I recall correctly, this was discussed here on the list and changed to 
>> the current behavior.
>> 
>> 
>>> 
 
> 
> What do y’all think?
> 
> Daniel Duan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution 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] [Discussion] mailing list alternative

[Goffredo Marocchi via swift-evolution]

Hello Ted,

I would actually be quite happy if we did rely on both JIRA and Discourse/forum 
for the different kinds of discussions as you were saying: sometimes I do 
believe that it is preferable to specialise more rather than add unwanted noise 
or inefficiency to a forced universal approach: different clear requirements 
requiring different solutions maybe a lot better than forcing a single 
compromise.

I think that although having two different places for discussions seems 
counterintuitive at first, as you said the adhoc and unstructured discussion of 
swift-dev or event swift-evolution at times does not really fit the JIRA model, 
but for bugs and proposals which are actually more self contained and 
structured work items the nature of JIRA fits a lot better and JIRA does offer 
a lot of integrations (with just a little bit of discipline keeping stories and 
GitHub PR's and commits too automatically linked is not hard at all).

At work we do use JIRA for bugs/stories/spikes as well as all the discussion 
directly related to each of them and Confluence/HipChat/e-mail (although I 
think Discourse would fit an important niche for us).
For bugs and stories you want to avoid noise or getting proposals lost, you 
want to be able to track their progress towards deliverable, etc... I am not 
here trying to sell you guys on JIRA ;), but I think that to use it effectively 
you would want the bug/stories filled with the right level of detail and with 
the directly connected discussion happening on the JIRA ticket as well (a JIRA 
ticket like a user story in agile is a conversation).

Kind Regards,

Goffredo

Sent from my iPhone

> On 31 Jan 2017, at 03:49, Ted kremenek via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 27, 2017, at 4:21 PM, Karl Wagner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution 
>>>  wrote:
>>> 
>>> I'm surprised there is so little support for JIRA. Anyone think it's a bad 
>>> tool for the job?
>>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution 
>>>  wrote:
 On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution 
  wrote:
 I haven't yet seen a good answer to the question: who is going to put in 
 the long-term commitment to host and maintain a replacement solution, 
 moderate forums, make technical upgrades and backups, and perform all the 
 other maintenance and administrative work it takes to properly run a 
 system like Discourse, a web forum, or even a bug tracker.
 
 I will volunteer to be a moderator of the Swift forums. I have time 
 available, and the core team surely has better things to do.
 
 Nevin
 ___
 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
>> 
>> Personally, I’d prefer if we used GitHub Issues. I like keeping the current 
>> state of the project together with the known issues in it. It also has 
>> better formatting and actually supports some kind of syntax highlighting for 
>> Swift code.
> 
> We did not go with GitHub Issues for our bug tracking for a few reasons (in 
> no particular order):
> 
> (1) At the time Swift became open source, GitHub did not support arbitrary 
> attachments to issues, which seemed a non-starter since it is important to 
> allow users to be able to file meaningful bug reports with reproducible test 
> cases.  This has since been resolved.
> 
> (2) The locus of everything on GitHub is the repository.  The Swift project 
> spans a bunch of repositories, and we felt it was not desirable to have 
> GitHub Issues, at least for the purposes of bug-tracking, on a per repository 
> level.  Instead, we wanted a central place to file issues that had its own 
> affordances for organizing them.  This is important for many reasons.  First, 
> not all the logical "sub-components" have their own repositories, and it is 
> important to distinguish in the bug-tracker the differences between (say) 
> compiler and standard library bugs.  We also found that users frequently do 
> not know what component — even if they are separate repositories in GitHub — 
> to file a bug report against, and often get it wrong.  Having a central bug 
> database allows us to move things around.  JIRA also provides a lot more 
> tools out of the box for managing issues at scale.
> 
> Note that syncing with other bug tracking systems is not an issue with either 
> JIRA or GitHub Issues, since both provide nice web services APIs for querying 
> them.
> 
> I completely agree that GitHub provides a nicer 

Re: [swift-evolution] Initializers

[David Hart via swift-evolution]

> On 30 Jan 2017, at 23:08, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 12:36 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> This seems to contradict Swift’s goal of being safe by default, no?  It 
>> would make me incredibly uncomfortable if there were a backdoor in DI, even 
>> if that backdoor emitted traps when it fails.
> 
> There already is a backdoor of sorts. This is one of the intended use cases 
> for implicitly-unwrapped optionals. If you don't want to be hassled by DI, 
> declare a property as T! type, and it will be implicitly initialized to nil, 
> and trap if you try to use it as an unwrapped T without initializing it first.

And we've been trying to close that door  :)

> -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] Subclass Existentials

[David Hart via swift-evolution]

> On 29 Jan 2017, at 23:12, Xiaodi Wu  wrote:
> 
>> On Sun, Jan 29, 2017 at 4:01 PM, David Hart via swift-evolution 
>>  wrote:
>> Hi Matthew,
>> 
>> I’ll reply to this post, because it allows me to discuss a few of the points 
>> in the discussion, but I’ve read the whole discussion.
>> 
>>> On 29 Jan 2017, at 18:30, Matthew Johnson  wrote:
>>> 
>>> Hi David,
>>> 
>>> This looks like a great start.
>>> 
>>> One thing we should consider is whether we tie this proposal so tightly to 
>>> classes or whether it might be better to call these supertype constraints.  
>>> The feature might also be useful for value types if / when Swift gets value 
>>> subtyping.
>> 
>> This makes sense, especially with the Substring : String discussions going 
>> on. When I rework the proposal, I’ll try to make it more general.
>> 
>>> One enhancement that might be worth considering.  Specifically, allowing 
>>> protocols to declare a specific supertype requirement in the place where a 
>>> `class` constraint would usually be found.  After this proposal we could 
>>> already do something similar using a `class` constraint to define a 
>>> protocol and a typealias to bind it to the supertype requirement.  It seems 
>>> like allowing users to state this more directly would be a good idea.
>> 
>> You lost me there. Can you give examples?
>> 
>>> As only the first element in the existential composition syntax can be a 
>>> class type, and by extending this rule to typealias expansions, we can make 
>>> sure that we only need to read the first element to know if it contains a 
>>> class requirement.
>>> 
>>> I think this is unnecessarily limiting in a couple of ways.  I agree that a 
>>> class should come first if it is mentioned explicitly***.  I am less sure 
>>> we should require this when the type is part of a typealias combined with 
>>> other protocol requirements.
>> 
>> I agree with Chris that I think it’s important to require the class be 
>> mentioned first when the class is mentioned explicitly. Even if we lost the 
>> Any syntax, there is still enough similarity to a class’s 
>> inheritance/conformance clause to keep the consistency and readability.
>> 
>>> For example, one use case I remember discussing with Austin is refining 
>>> supertype requirements.  If I have a typealias which requires a superclass 
>>> `Base` I should be able to form an existential using that typealias that 
>>> *refines* that requirement to some type *Derived* which is a non-final 
>>> subtype of `Base`.  This would require syntax that allows us to put a class 
>>> name in the first position, but also mention a typealias with a supertype 
>>> requirement in a subsequent position.
>> 
>> I’ve read the examples in the thread and I think I agree that those cases 
>> should be accepted. But just to make sure we are on the same page, what does 
>> everyone think of the validity of the following cases? For shorthand, I use 
>> parentheses to represent typealias expansion. For example, when I write:
>> 
>> Protocol1 & (Protocol2 & Protocol3)
>> I mean:
>> 
>> typealias Something = Protocol2 & Protocol3
>> Protocol1 & Something
>> Questions
>> 
>> Should class requirements be fixed to first position? I.e., should Protocol 
>> & Base be valid and equivalent to Base & Protocol?
>> Should repetition of class requirements in the same declaration be allowed? 
>> I.e., should Base & Base be valid and equivalent to Base?
>> Should repetition of class requirements through typealias expansion be 
>> allowed? I.e., should Base & (Base & Protocol) be valid and equivalent to 
>> Base & Protocol?
>> Should type and sub-type requirements in the same declaration be allowed? 
>> I.e., should Base & Derived or Derived & Base be valid and equivalent to 
>> Derived?
>> Should type and sub-type requirements through typealias expansion be 
>> allowed? I.e., should Base & (Derived & Protocol) or Derived & (Base & 
>> Protocol) be valid and equivalent to Derived & Protocol?
>> My Answers
>> 
>> No, for the reasons stated above.
>> No, because it doesn’t make sense to repeat it in the same declaration.
>> Yes, I’m gonna start agreeing with you and think will ease typealias 
>> composition.
>> No, for the same reasons as 2.
>> Yes, for the same reasons as 3.
> That's a _reasonable_ set of answers if you want to require Base to precede 
> Protocol *and* you want to ease rules for typealiases. However, using your 
> notation, should `(Protocol & Protocol) & (Base & Protocol)` be allowed?

Yes, it would be allowed. I'll mention this example when I write the proposals 
second draft. Thanks!

> If not, your rules will have to get pretty complicated. OTOH, if so, it seems 
> like an awfully heavy-handed yet simultaneously ineffective hardcoding of a 
> style preference, since I'd be able to use `typealias Base_ = Base & Any` to 
> circumvent the rule any time I like.
> 
> 
>> David.
>> 
>>> 

Re: [swift-evolution] Warn about unused Optional.some(())

[Daniel Duan via swift-evolution]

I guess I missed that discussion. This "feature" does more harm than good IMHO.

> On Jan 30, 2017, at 10:16 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Jan 31, 2017, at 1:03 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
  wrote:
 
 Hi all,
 
 Right now, expressions that evaluates to Optional<()>, 
 Optional>… gets special treatment when it’s unused. For 
 example:
 
 func f(s: String) {}
 let s: String = “”
 s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
 and unused.
 
 func g() throws {}
 try? g() // no warnings here neither.
 
 This is convenient, but encourages composing map/filter/reduce, etc with 
 side-effect-ful functions, which we have found a few cases of in our 
 production code recently. Granted, these cases could’ve been caught with 
 more careful code reviews. But we wouldn’t have missed them if this 
 “feature” didn’t exist.
 
 I think we should remove the special treatment so that code in the example 
 above would generate a warning about `()?` being unused. Users can silence 
 it manually by assigning the result to `_`. 
 
 OTOH, this would undermine the convenience of `try?` when the throwing 
 function don’t return anything.
>>> 
>>> IMHO, using ‘try?’ to ignore an error result, instead of just turning it 
>>> into an optional, is an anti-pattern, and forcing users to write ‘_ = try? 
>>> foo()’ might not be so bad…
>> 
>> +1
> 
> Isn't this how it was in Swift 2.x and the first versions of 3.0? I believe 
> this was changed only recently - which I personally found as good news. In 
> some cases you simply do not care about the error result since it has no 
> impact if the call fails and typing "_ =" seemed like boilerplate...
> 
> If I recall correctly, this was discussed here on the list and changed to the 
> current behavior.
> 
> 
>> 
>>> 
 
 What do y’all think?
 
 Daniel Duan
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Warn about unused Optional.some(())

[Charlie Monroe via swift-evolution]

> On Jan 31, 2017, at 1:03 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Right now, expressions that evaluates to Optional<()>, 
>>> Optional>… gets special treatment when it’s unused. For 
>>> example:
>>> 
>>> func f(s: String) {}
>>> let s: String = “”
>>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
>>> and unused.
>>> 
>>> func g() throws {}
>>> try? g() // no warnings here neither.
>>> 
>>> This is convenient, but encourages composing map/filter/reduce, etc with 
>>> side-effect-ful functions, which we have found a few cases of in our 
>>> production code recently. Granted, these cases could’ve been caught with 
>>> more careful code reviews. But we wouldn’t have missed them if this 
>>> “feature” didn’t exist.
>>> 
>>> I think we should remove the special treatment so that code in the example 
>>> above would generate a warning about `()?` being unused. Users can silence 
>>> it manually by assigning the result to `_`. 
>>> 
>>> OTOH, this would undermine the convenience of `try?` when the throwing 
>>> function don’t return anything.
>> 
>> IMHO, using ‘try?’ to ignore an error result, instead of just turning it 
>> into an optional, is an anti-pattern, and forcing users to write ‘_ = try? 
>> foo()’ might not be so bad…
> 
> +1

Isn't this how it was in Swift 2.x and the first versions of 3.0? I believe 
this was changed only recently - which I personally found as good news. In some 
cases you simply do not care about the error result since it has no impact if 
the call fails and typing "_ =" seemed like boilerplate...

If I recall correctly, this was discussed here on the list and changed to the 
current behavior.


> 
>> 
>>> 
>>> What do y’all think?
>>> 
>>> Daniel Duan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] The lack of namespaces is leading people astray

[Russ Bishop via swift-evolution]

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution 
>  wrote:
> 
> The lack of namespaces is making people create all kinds of "design patterns".
> 
> 
> What do you think?
> 

I’ve used languages with namespaces for many years. I don’t find multi-level 
namespaces to be much of an improvement over a single-level namespace in most 
cases. On the contrary, I find it much simpler to avoid hunting around 
importing a hundred namespaces. This is what you end up with:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using System.Web;
using System.Net ;
using System.Net .HttpClient;



The only thing we really need in Swift is the ability to have a Private 
submodule, especially for mixed-mode frameworks.


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

Re: [swift-evolution] extending typealiases

[Matt Whiteside via swift-evolution]

Thanks for these explanations.  It sounds like you guys want to build this 
feature so it's just a matter of waiting until it has the priority.   

Until then, every box that gets checked on the generics manifesto is much 
appreciated.

-Matt

> On Jan 30, 2017, at 15:17, Douglas Gregor  wrote:
> 
> 
>>> On Jan 29, 2017, at 8:35 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution 
>>>  wrote:
>>> 
>>> In Swift 3.1, I was happy to see that we can now extend types with concrete 
>>> constraints.  I think one other feature which fits nicely with this new 
>>> capability would be extending typealiases, like this:
>>> 
>>> typealias Vector = Array
>>> 
>>> extension Vector { 
>>>...
>>> }
>>> 
>>> Which currently doesn't compile due to:  "Constrained extension must be 
>>> declared on the unspecialized generic type 'Array' with constraints 
>>> specified by a 'where’ clause”
>>> 
>>> What is other people’s interest level?  How possible would it be to add 
>>> this?
>> 
>> I think this particular case would be pretty easy to add, but there is a 
>> more general case with generic typealiases that requires some thought:
>> 
>> typealias OptionalArray = Optional
>> 
>> extension OptionalArray {
>>   …
>> }
>> 
>> Without generic typealiases, you might imagine this could be written as 
>> something like
>> 
>> extension  Optional {
>>   …
>> }
>> 
>> I think this is called out in the generics manifesto as a potential future 
>> feature. I’m not sure how much work it would take to add it but I imagine 
>> it’s not entirely trivial.
> 
> The implementation here would probably not be trivial. There are two general 
> issues, the first of which also applies to extending typealiases:
> 
> 1) The type checker doesn’t have a principled way of resolving the name of 
> the extended type, so to correctly look through typealiases would require a 
> bunch of reworking of the way we do lookup there. This would be a fantastic 
> improvement to the compiler and would fix a bunch of bugs with extending 
> nested types, too :)
> 
> 2) There are undoubtedly a number of places in the compiler where we assume 
> that the generic parameters of an extension are the same as the generic 
> parameters of the nominal type, but this will no longer be true if we allow 
> extension of generic typealiases. For example:
> 
> struct Pair { }
> 
> typealias Array2 = Pair
> 
> extension Array2 { // extension has one generic parameter, but Pair has two 
> generic parameters
> }
> 
> It’s likely not *hard* to fix these issues, but it’ll be a game of 
> whack-a-mole throughout the compiler.
> 
>   - Doug
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Xiaodi Wu via swift-evolution]

On Mon, Jan 30, 2017 at 10:08 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> I mean that `OptionSet.RawValue` currently has to conform to
> >> `BitwiseOperations`,
> >
> > Actually it doesn't.  You just have to implement these yourself in that
> > case:
> >
> >  extension OptionSet where Self.RawValue : BitwiseOperations {
>
> Oh, I didn't realize it was implemented that way (and was going to stay
> that way). Thanks for the correction.
>
> >> but would now need to conform to `BinaryInteger` (or a sub-protocol).
> >
> > Does that limit you in some useful way?
>
> Well, a type like `Data` could be usefully conformed to
> `BitwiseOperations`, which would permit its use as a variable-sized bit
> buffer, but conforming it to `BinaryInteger` would make no sense and might
> cause mis-conformances. (For instance, `BinaryInteger.Type.+` and the `+`
> operator that works on `RangeReplaceableCollection`s like `Data` are
> incompatible). You would instead have to use a big-int type, but it's
> apparently common for those to be implemented in ways that make bitwise
> operations slow.
>

Having implemented a bit vector in Swift (then found it to be slow, then
asked for leadingZeros the last time this proposal came round), I totally
agree that it would be one such type that conforms to the syntax and
semantics of `BitwiseOperations`.

I was initially bummed to see it go as well, but on reflection I think it's
the right decision. The question is, what interesting algorithm could you
actually write that would be generic over BitwiseOperations? I couldn't
think of any. Sure, I could use an Int like a BitVector, but if I wanted to
use the instance only for bitwise operations, I'd just use a word-sized
BitVector. Perhaps you have other use cases?


> However, unless I'm mistaken, I believe a `BitwiseOperations` protocol
> could be extracted from `BinaryInteger` later (right? Resilience permits
> you to add a new super-protocol and move some of the sub-protocol's
> requirements up into it?), so we can pick that up later.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[David Sweeris via swift-evolution]

> On Jan 30, 2017, at 8:14 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Just left a comment on the bug; it's clear we need some sort of new syntax, 
> and I'd like to throw out `foo(:)` as a candidate, by analogy with `[:]` 
> being an empty dictionary.

Works for me.

- Dave Sweeris

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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Xiaodi Wu via swift-evolution]

Just left a comment on the bug; it's clear we need some sort of new syntax,
and I'd like to throw out `foo(:)` as a candidate, by analogy with `[:]`
being an empty dictionary.
On Mon, Jan 30, 2017 at 22:04 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> You said "The ability to reference a function by only the first segment of
> its name is likewise legacy of the original model..." — how else could you
> refer to a nullary function? Even if labels were required for naming
> (>0)-ary functions, there's still ambiguity between a nullary function and
> a variable.
> On Mon, Jan 30, 2017 at 7:54 PM Joe Groff  wrote:
>
>
> > On Jan 30, 2017, at 7:34 PM, Jacob Bandes-Storch 
> wrote:
> >
> > Although there's no spelling for this...
> https://bugs.swift.org/browse/SR-3550
>
> IMO, the way to spell `foo` with no arguments is just `foo`. If we
> strictly required the labels for referring to n-ary functions, that would
> make it unambiguous…
>
> -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] protocol-oriented integers (take 2)

[Brent Royal-Gordon via swift-evolution]

> On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> I mean that `OptionSet.RawValue` currently has to conform to
>> `BitwiseOperations`, 
> 
> Actually it doesn't.  You just have to implement these yourself in that
> case:
> 
>  extension OptionSet where Self.RawValue : BitwiseOperations {

Oh, I didn't realize it was implemented that way (and was going to stay that 
way). Thanks for the correction.

>> but would now need to conform to `BinaryInteger` (or a sub-protocol).
> 
> Does that limit you in some useful way?

Well, a type like `Data` could be usefully conformed to `BitwiseOperations`, 
which would permit its use as a variable-sized bit buffer, but conforming it to 
`BinaryInteger` would make no sense and might cause mis-conformances. (For 
instance, `BinaryInteger.Type.+` and the `+` operator that works on 
`RangeReplaceableCollection`s like `Data` are incompatible). You would instead 
have to use a big-int type, but it's apparently common for those to be 
implemented in ways that make bitwise operations slow.

However, unless I'm mistaken, I believe a `BitwiseOperations` protocol could be 
extracted from `BinaryInteger` later (right? Resilience permits you to add a 
new super-protocol and move some of the sub-protocol's requirements up into 
it?), so we can pick that up later.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

You said "The ability to reference a function by only the first segment of
its name is likewise legacy of the original model..." — how else could you
refer to a nullary function? Even if labels were required for naming
(>0)-ary functions, there's still ambiguity between a nullary function and
a variable.
On Mon, Jan 30, 2017 at 7:54 PM Joe Groff  wrote:

>
> > On Jan 30, 2017, at 7:34 PM, Jacob Bandes-Storch 
> wrote:
> >
> > Although there's no spelling for this...
> https://bugs.swift.org/browse/SR-3550
>
> IMO, the way to spell `foo` with no arguments is just `foo`. If we
> strictly required the labels for referring to n-ary functions, that would
> make it unambiguous…
>
> -Joe
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Brent Royal-Gordon via swift-evolution]

> On Jan 30, 2017, at 11:31 AM, Max Moiseev  wrote:
> 
> doubleWidthDivide should not return a DoubleWidth for two reasons:
> 1. The components of it’s return type are not high and low, but are quotient 
> and remainder instead.
> 2. In DoubleWidth high is T and low is T.Magnitude, which is not the case 
> for quotient and remainder.

You're right about the return value; for `doubleWidthDivide(_:_:)`, I was 
thinking about changing the dividend. Specifically, I'm thinking we should 
change these to:

static func doubleWidthMultiply(_ lhs: Self, _ rhs: Self) -> 
DoubleWidth
static func doubleWidthDivide(_ lhs: DoubleWidth, _ rhs: Self) -> 
(quotient: Self, remainder: Self)

I'm also thinking a little bit about spelling of these operations. I'd *love* 
to be able to call them `*` and `/` and let the type system sort things out, 
but that would cause problems, especially for multiply (since the return value 
is the only thing different from a normal `*`). We could invent a new operator, 
but that would be a bit much. Could these be simply `multiply` and `divide`, 
and we'll permit the `DoubleWidth` parameter/return type to explain itself?

I'm also thinking the second parameter should be labeled `by`, since that's the 
way people talk about these operations. Applying both of these suggestions, 
we'd get:

static func multiply(_ lhs: Self, by rhs: Self) -> DoubleWidth
static func divide(_ lhs: DoubleWidth, by rhs: Self) -> 
(quotient: Self, remainder: Self)

let x = Int.multiply(a, by: b)
let (aʹ, r) = Int.divide(x, by: b)
assert(a == aʹ)
assert(r == 0)

Should the standard library provide extensions automatic definitions of 
multiplication and division in terms of their double-width equivalents?

extension FixedWidthInteger {
func multipliedWithOverflow(by other: Self) -> (partialValue: 
Self, overflow: ArithmeticOverflow) {
let doubledResult = Self.multiply(self, by: other)
let overflowed = doubledResult.high != (doubledResult < 
0 ? -1 : 0)
return (Self(bitPattern: doubledResult.lowerValue), 
overflowed ? .overflowed : .none)
}

func quotientAndRemainder(dividingBy other: Self) -> (quotient: 
Self, remainder: Self) {
precondition(other != 0, "Divide by zero")
return Self.divide(DoubleWidth(self), by: other)
}

func dividedWithOverflow(by other: Self) -> (partialValue: 
Self, overflow: ArithmeticOverflow) {
guard other != 0 else { return (self, .overflowed) }

let result = Self.divide(self, by: other)
return (result.quotient, .none)
}

static func * (lhs: Self, rhs: Self) -> Self {
let result = lhs.dividedWithOverflow(by: rhs)
precondition(result.overflow == .none, "Multiplication 
overflowed")
return result.partialValue
}

static func / (lhs: Self, rhs: Self) -> Self {
let result = lhs.quotientAndRemainder(dividingBy: rhs)
return result.quotient
}

static func % (lhs: Self, rhs: Self) -> Self {
let result = lhs.quotientAndRemainder(dividingBy: rhs)
return result.remainder
}
}

Hmm...having actually written this out, I now have a couple of concerns:

1. There's a lot of jumping back and forth between instance methods and static 
methods. Can we standardize on just static methods? Or make sure that the 
user-facing interfaces are all either operators or instance methods?

2. There is no quotient-and-remainder-with-overflow, either regular or 
double-width. Can we do that?

3. "Overflow" is not really a good description of what's happening in division; 
the value is undefined, not overflowing. Is there a better way to express this?

4. For that matter, even non-fixed-width division can "overflow"; should that 
concept be hoisted higher up the protocol hierarchy?

5. For *that* matter, should we simply make these operations throw instead of 
returning a flag?

enum ArithmeticError: Error {
// Are generic errors permitted?
case overflow(partialValue: NumberType)
case undefined
}

// Should these throwing definitions be higher up so that, when working 
with `Arithmetic` 
// or similar types, you have an opportunity to handle errors instead 
of always trapping?
protocol FixedWidthInteger: BinaryInteger {
...
func adding(_ other: Self) throws -> 

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Joe Groff via swift-evolution]

> On Jan 30, 2017, at 7:34 PM, Jacob Bandes-Storch  wrote:
> 
> Although there's no spelling for this... https://bugs.swift.org/browse/SR-3550

IMO, the way to spell `foo` with no arguments is just `foo`. If we strictly 
required the labels for referring to n-ary functions, that would make it 
unambiguous…

-Joe

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

Re: [swift-evolution] [Discussion] mailing list alternative

[Ted kremenek via swift-evolution]

> On Jan 27, 2017, at 4:21 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I'm surprised there is so little support for JIRA. Anyone think it's a bad 
>> tool for the job?
>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution 
>>>  wrote:
>>> I haven't yet seen a good answer to the question: who is going to put in 
>>> the long-term commitment to host and maintain a replacement solution, 
>>> moderate forums, make technical upgrades and backups, and perform all the 
>>> other maintenance and administrative work it takes to properly run a system 
>>> like Discourse, a web forum, or even a bug tracker.
>>> 
>>> I will volunteer to be a moderator of the Swift forums. I have time 
>>> available, and the core team surely has better things to do.
>>> 
>>> Nevin
>>> ___
>>> 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
> 
> Personally, I’d prefer if we used GitHub Issues. I like keeping the current 
> state of the project together with the known issues in it. It also has better 
> formatting and actually supports some kind of syntax highlighting for Swift 
> code.

We did not go with GitHub Issues for our bug tracking for a few reasons (in no 
particular order):

(1) At the time Swift became open source, GitHub did not support arbitrary 
attachments to issues, which seemed a non-starter since it is important to 
allow users to be able to file meaningful bug reports with reproducible test 
cases.  This has since been resolved.

(2) The locus of everything on GitHub is the repository.  The Swift project 
spans a bunch of repositories, and we felt it was not desirable to have GitHub 
Issues, at least for the purposes of bug-tracking, on a per repository level.  
Instead, we wanted a central place to file issues that had its own affordances 
for organizing them.  This is important for many reasons.  First, not all the 
logical "sub-components" have their own repositories, and it is important to 
distinguish in the bug-tracker the differences between (say) compiler and 
standard library bugs.  We also found that users frequently do not know what 
component — even if they are separate repositories in GitHub — to file a bug 
report against, and often get it wrong.  Having a central bug database allows 
us to move things around.  JIRA also provides a lot more tools out of the box 
for managing issues at scale.

Note that syncing with other bug tracking systems is not an issue with either 
JIRA or GitHub Issues, since both provide nice web services APIs for querying 
them.

I completely agree that GitHub provides a nicer interface than JIRA, and would 
be one less tool for us to use.  Unfortunately, it doesn't match with some 
important workflows we have in mind for bug tracking.  It forces an 
organization of issues that doesn't match with what the project needs.  If 
those problems did not exist, we'd almost certainly be using GitHub Issues for 
issue tracking as that would more tightly match with the development workflows 
of the rest of the project (e.g., pull requests).

It's an interesting idea to use GitHub Issues or JIRA essentially as a forum — 
but it feels a bit too structured.  I pretty much share Goffredo's opinion here 
on the value of a forum like Discourse versus using a tool like JIRA for 
discussions.  The discussions on swift-dev or swift-evolution often are just 
discussion or even chatter — important chatter, but unstructured and ad hoc.  I 
can see something like GitHub Issues being a useful way for tracking more 
official discussions, such as when a proposal is getting official discussed, 
but I'm not certain if doing something different for those kinds of discussions 
than what are done for the informal shop-and-idea-around discussions on the 
mailing list would be worth it.

> 
> I just assumed that some of our requirements (e.g. syncing with Apple’s 
> internal “radar” system) disqualified it.
> 
> The reason why we don’t have topics every month about migrating our 
> bug-tracking system is that JIRA (while perhaps not optimal) is at least 
> passable. That’s more than you can say for the mailing lists, most of the 
> time.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

Although there's no spelling for this...
https://bugs.swift.org/browse/SR-3550
On Mon, Jan 30, 2017 at 7:29 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 30, 2017, at 11:42 AM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The reason Swift works like this is because you can assign a function
> value (independently of calling it) to a variable. So there aren't two
> separate namespaces separating function names and variable names.
>
> To be honest, I would say that there's no "reason" for this, except as
> lingering effects of our early "functions have simple names, and arguments
> have labeled tuple type" model. If we had originally implemented the
> language with its current (at least aspirational) Smalltalk-ish
> compound-names model, we probably would have ended up allowing this, since
> the var and func do formally have different names. The ability to reference
> a function by only the first segment of its name is likewise legacy of the
> original model, though it happens to be useful since good naming hygiene
> encourages different base names for different things to begin with.
>
> -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] Why doesn't Swift allow a variable and a function with the same name?

[Joe Groff via swift-evolution]

> On Jan 30, 2017, at 11:42 AM, Austin Zheng via swift-evolution 
>  wrote:
> 
> The reason Swift works like this is because you can assign a function value 
> (independently of calling it) to a variable. So there aren't two separate 
> namespaces separating function names and variable names.

To be honest, I would say that there's no "reason" for this, except as 
lingering effects of our early "functions have simple names, and arguments have 
labeled tuple type" model. If we had originally implemented the language with 
its current (at least aspirational) Smalltalk-ish compound-names model, we 
probably would have ended up allowing this, since the var and func do formally 
have different names. The ability to reference a function by only the first 
segment of its name is likewise legacy of the original model, though it happens 
to be useful since good naming hygiene encourages different base names for 
different things to begin with.

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard via swift-evolution]

> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>  wrote:
> 
> Hello Boris,
> 
>> Am 25.01.2017 um 19:10 schrieb Boris Buegling > >:
>>> But instead of hard-coding some version into the manifest, we should allow 
>>> to specify dependencies without any version requirement.
>>> The concrete branch/version specification should always be stored in the 
>>> `Package.pins` file.
>>> This way, we also don't have any problem with conflicting branch 
>>> specifications.
>> 
>> While this is true for most packages, some have a development model where 
>> they will always depend on a branch and never on a version. In that case, it 
>> is more semantically correct to have the branch definition in the manifest, 
>> otherwise the package would not be able to build without a pins file. 
>> 
>> This is especially true for the example from the proposal:
>> 
>> A -> (B:master, C:master) B -> D:branch1 C -> D:branch2
>> 
>> Since the pins file of packages B and C would not be considered when 
>> building A, you would need to lift the pinning that is inherent to those 
>> packages up to the pins file of A.
> 
> OK, you are right, branches can be helpful to have in the manifest.
> But I’m still confident that we must not put explicit version information 
> into it.
> They belongs into the `Package.pins` file.
> That is enough to get reproducible builds.

Hi Martin,

By "explicit version information", do you mean that you shouldn't put a git 
revision hash in the manifest – only branches and version tags should be 
acceptable?

I'd agree that the revision-based initializer is a marginal feature; normally 
your package should depend on a version range or is tracking a branch. That 
said, we can imagine that you might wind up needing to peg your dependency to a 
specific revision that isn't a version tag, and not track a moving branch, so 
this seemed like a fairly harmless feature to add for that case. What is your 
objection about supporting that?

The decision about whether to put this information in your pins or in your 
manifest should be driven by whether it's something your package requires, or 
is just a workflow choice. If you just want to temporarily stick to a specific 
revision of your dependency for workflow reasons, pinning is the right way to 
do that. If, however, your package currently requires that revision, and isn't 
going to work properly without it, then the manifest is the right way to 
express that. You'd want that specification to stick even if someone did `swift 
package update --repin` to get newer pinned revisions.

- Rick

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard via swift-evolution]

> On Jan 30, 2017, at 12:41 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Jan 24, 2017, at 10:18 AM, Daniel Dunbar  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0150 “ Package Manager Support for branches" begins now and 
>> runs through January 31, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-build-dev and swift-evolution mailing lists at
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
>> 
>> 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?
> +1
> I would even go a bit further and suggest that "Package(url: String, branch: 
> String)” should have “master” be the default value for `branch`, to make it 
> simpler for small developer teams who don’t necessarily have all the 
> collaboration issues of large projects.

This would make it easier to bring up your first set of packages without typing 
in as many parameters. But I have a couple concerns:

– A user who forgets to supply a second parameter could wind up accidentally 
depending on master when they didn't intend to. The normal case is to depend on 
a versioned tag, and we shouldn't make it too easy to mistakenly do otherwise.

– This would make it less obvious to someone reading a Package.swift manifest 
that a one of the dependencies is untagged. That's a potentially dangerous 
situation if you're not expecting it, so it should be visible, not implicit.

I think we should err on the side of making this explicit, since it is 
important, even if it means a little bit of extra typing when you're bringing 
up your first packages.

- Rick

>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> IMHO, yes. Particularly since Xcode doesn’t support git tags (that I can 
> find, anyway)
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> IMOH, yes. This proposal will make development with much easier for 
> programmers whose work-flow is branch-based rather than tag-based.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> An embarrassingly long time trying to figure out why a package wasn’t seeing 
> changes I’d committed to one of its dependencies... Somewhere along the line 
> I must’ve accidentally created a branch called “1.0.0”, which lead to me 
> conflating the 1.0.0 tag with the 1.0.0 branch, which has caused me no end of 
> head scratching.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

[Rick Ballard via swift-evolution]

Hi Derrick,

This use case can be solved using `pin --branch`.

If you really wanted to, you could also simply add B as a direct dependency of 
P to specify a branch; there's no need to "nest" the dependency. If P really 
does depend on B being on a branch, the manifest for P may be the right place 
to express that. In general, however, I'd expect that the case you're 
describing is a workflow use-case, and thus should be accomplished with 
pinning; it seems uncommon that a package would truly depend on one of its 
indirect dependencies being on a branch.

If you'd like to discuss this further, please reply on the "Package Manager 
Support for branches" thread, as (if I understand you correctly) your question 
is about that proposal, not the "Top of Tree development" proposal.

Thanks,

- Rick

> On Jan 27, 2017, at 6:42 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> Boris,
> 
> My Intent is to make it easier to develop dependency B. I may want to develop 
> on a feature branch for dependency B so I'd like to use PM to force that to 
> happen. 
> 
> I don't want to have to cd into the A folder and then cd into B to make that 
> change. I want to control the whole thing from the root git repo

>> On Jan 25, 2017, at 10:40 AM, Boris Buegling via swift-evolution 
>>  wrote:
>> 
>> Hi Derrick,
>> 
>> I think you meant to send this as a reply to SE-0149 Package Manager Support 
>> for branches, correct?
>> 
>> I’m not quite sure about the use case for your described behaviour, can you 
>> elaborate a bit more why you would want to override a dependency of A from 
>> the manifest of P? 
>> 
>> If the goal is a temporary override, the proposal already allows that by 
>> utilising `pin --branch`.
>> 
>> Cheers,
>> Boris
>> 
>>> On 25 Jan 2017, at 01:50, Derrick Ho via swift-evolution 
>>>  wrote:
>>> 
>>> It probably is a good idea.
>>> 
>>> Perhaps the changes can be done in the Package.swift file but allow nesting 
>>> of dependencies.
>>> 
>>> Suppose your dependency is like this where P is your current project
>>> 
>>> P --> A --> B
>>> 
>>> Normally P we would describe its dependency on A while B would be 
>>> abstracted away. In A, there would be another Package.swift file describing 
>>> its dependency on B.
>>> 
>>> However if we add the ability to NEST the dependency graph in P's 
>>> Package.swift it could serve as an override to the default behavior.
>>> 
>>> import PackageDescription
>>> 
>>> let package = Package(
>>> name: "P",
>>> targets: [],
>>> dependencies: [
>>> .Package(url: "https://blah.com/A.git;,
>>> majorVersion: 1, depdencies: [
>>> .Package(url: "https://blahblah.com/B.git, branch: "test")
>>> ]),
>>> 
>>> ]
>>> )

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

Re: [swift-evolution] Strings in Swift 4

[James Froggatt via swift-evolution]

Going to try resending this - my client doesn't seem to give me a proper email 
address to reply to (only some gmane mangled address which got me a delivery 
failure); sorry for the lack of a direct reply.

---

Exactly. I'm not too familiar with range subscripting on arrays, but if it's 
anything like a regular Int subscript, I'd expect…

let outOfBoundsSubrange = items[items.startIndex...items.endIndex]

…to give an out of bounds error, since (in my mental model) it tries to access 
items[items.endIndex].


If ‘items.startIndex...’ represents an unbounded range (one with a unknown / 
subscript-defined endIndex), I can't see enough use-cases for it outside of 
subscripting to justify its existence as a type - it can't even conform to 
sequence, since there is no endIndex, making it essentially just a number and a 
promise of how APIs will use it. If we pretend an unbounded range is infinite 
by conforming it to sequence, people will inevitably use it like one.

If this syntax represents an infinite range, I'd expect it to similarly give an 
error when used to subscript a non-infinite array-like type, but it would at 
least be independently useful outside of collections as a way to generate an 
infinite sequence.


As a further point, what if we also implemented prefix comparison operators? 
Which of the following looks more like an infinite range, and which looks more 
like an unbounded one? I'll leave the answer up to the reader:

let indices = >oneDigitNums.startIndex
oneDigitNums[>5]

let indices = oneDigitNums.startIndex...
oneDigitNums[5...]



 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID:  


> On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Why should that be out-of-bounds?  Whether it is out-of-bounds would
> depend on what items is.  If it's an array, that should be equivalent to
> 
> let x = items[items.startIndex..

Re: [swift-evolution] [Discussion] mailing list alternative

[Jacob Bandes-Storch via swift-evolution]

Plus (heart), but not minus. Although it looks like someone has written a
plugin for this:
https://meta.discourse.org/t/retort-a-reaction-style-plugin-for-discourse/35903

On Mon, Jan 30, 2017 at 5:35 PM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> Does Discourse allow stuff to be "plus-one-ed"? I like how Reddit has this
> feature and I notice that many people on this mailing list either -1 or +1
> something.
>
> I feel like it is very democratic.
>
> On Mon, Jan 30, 2017 at 10:52 AM Rudolf Adamkovič via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1 for either e-mail or GitHub issues. No need for yet another tool...
>>
>> R+
>>
>> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I'm surprised there is so little support for JIRA. Anyone think it's a
>> bad tool for the job?
>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via
>> swift-evolution  wrote:
>>
>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I haven't yet seen a good answer to the question: who is going to put in
>> the long-term commitment to host and maintain a replacement solution,
>> moderate forums, make technical upgrades and backups, and perform all the
>> other maintenance and administrative work it takes to properly run a system
>> like Discourse, a web forum, or even a bug tracker.
>>
>>
>> I will volunteer to be a moderator of the Swift forums. I have time
>> available, and the core team surely has better things to do.
>>
>> Nevin
>> ___
>> 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
>>
>>
>> Personally, I’d prefer if we used GitHub Issues. I like keeping the
>> current state of the project together with the known issues in it. It also
>> has better formatting and actually supports some kind of syntax
>> highlighting for Swift code.
>>
>> I just assumed that some of our requirements (e.g. syncing with Apple’s
>> internal “radar” system) disqualified it.
>>
>> The reason why we don’t have topics every month about migrating our
>> bug-tracking system is that JIRA (while perhaps not optimal) is at least
>> passable. That’s more than you can say for the mailing lists, most of the
>> time.
>>
>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Warn about unused Optional.some(())

[Daniel Duan via swift-evolution]

As implemented, no. Whether it should be affected is another topic...

> On Jan 30, 2017, at 5:17 PM, James Froggatt via swift-evolution 
>  wrote:
> 
> Would this affect optional chaining? ( a?.voidReturningFunc() also evaluates 
> to ()? )
> 
>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID: <1fa68175-bc14-4e61-aece-a80b79d55...@apple.com> 
> 
> 
>> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Right now, expressions that evaluates to Optional<()>, 
>> Optional>… gets special treatment when it’s unused. For example:
>> 
>> func f(s: String) {}
>> let s: String = “”
>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
>> and unused.
>> 
>> func g() throws {}
>> try? g() // no warnings here neither.
>> 
>> This is convenient, but encourages composing map/filter/reduce, etc with 
>> side-effect-ful functions, which we have found a few cases of in our 
>> production code recently. Granted, these cases could’ve been caught with 
>> more careful code reviews. But we wouldn’t have missed them if this 
>> “feature” didn’t exist.
>> 
>> I think we should remove the special treatment so that code in the example 
>> above would generate a warning about `()?` being unused. Users can silence 
>> it manually by assigning the result to `_`. 
>> 
>> OTOH, this would undermine the convenience of `try?` when the throwing 
>> function don’t return anything.
> 
> IMHO, using ‘try?’ to ignore an error result, instead of just turning it into 
> an optional, is an anti-pattern, and forcing users to write ‘_ = try? foo()’ 
> might not be so bad…
> 
>> 
>> What do y’all think?
>> 
>> Daniel Duan
>> ___
>> 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
> 
> 
> - End Message - 
> 
> 
> 
> From James
> ___
> 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] [Discussion] mailing list alternative

[Derrick Ho via swift-evolution]

Does Discourse allow stuff to be "plus-one-ed"? I like how Reddit has this
feature and I notice that many people on this mailing list either -1 or +1
something.

I feel like it is very democratic.
On Mon, Jan 30, 2017 at 10:52 AM Rudolf Adamkovič via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for either e-mail or GitHub issues. No need for yet another tool...
>
> R+
>
> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm surprised there is so little support for JIRA. Anyone think it's a bad
> tool for the job?
> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I haven't yet seen a good answer to the question: who is going to put in
> the long-term commitment to host and maintain a replacement solution,
> moderate forums, make technical upgrades and backups, and perform all the
> other maintenance and administrative work it takes to properly run a system
> like Discourse, a web forum, or even a bug tracker.
>
>
> I will volunteer to be a moderator of the Swift forums. I have time
> available, and the core team surely has better things to do.
>
> Nevin
> ___
> 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
>
>
> Personally, I’d prefer if we used GitHub Issues. I like keeping the
> current state of the project together with the known issues in it. It also
> has better formatting and actually supports some kind of syntax
> highlighting for Swift code.
>
> I just assumed that some of our requirements (e.g. syncing with Apple’s
> internal “radar” system) disqualified it.
>
> The reason why we don’t have topics every month about migrating our
> bug-tracking system is that JIRA (while perhaps not optimal) is at least
> passable. That’s more than you can say for the mailing lists, most of the
> time.
>
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[James Froggatt via swift-evolution]

Exactly. I'm not too familiar with range subscripting on arrays, but if it's 
anything like a regular Int subscript, I'd expect…

let outOfBoundsSubrange = items[items.startIndex...items.endIndex]

…to give an out of bounds error, since (in my mental model) it tries to access 
items[items.endIndex].


If ‘items.startIndex...’ represents an unbounded range (one with a unknown / 
subscript-defined endIndex), I can't see enough use-cases for it outside of 
subscripting to justify its existence as a type - it can't even conform to 
sequence, since there is no endIndex, making it essentially just a number and a 
promise of how APIs will use it. If we pretend an unbounded range is infinite 
by conforming it to sequence, people will inevitably use it like one.

If this syntax represents an infinite range, I'd expect it to similarly give an 
error when used to subscript a non-infinite array-like type, but it would at 
least be independently useful outside of collections as a way to generate an 
infinite sequence.


As a further point, what if we also implemented prefix comparison operators? 
Which of the following looks more like an infinite range, and which looks more 
like an unbounded one? I'll leave the answer up to the reader:

let indices = >oneDigitNums.startIndex
oneDigitNums[>5]

let indices = oneDigitNums.startIndex...
oneDigitNums[5...]



 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID:  


>On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution 
> wrote:
>
>Why should that be out-of-bounds?  Whether it is out-of-bounds would
>depend on what items is.  If it's an array, that should be equivalent to
>
>let x = items[items.startIndex..

Re: [swift-evolution] The lack of namespaces is leading people astray

[Derrick Ho via swift-evolution]

If you make a dynamic framework called APIFramework
And add a public class called URL_ME

You can instantiate it with APIFramework.URL_ME() from your project.


I haven't tried to see if this would work with global variables but I
assume it would.
On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> I submitted a proposal with TJ a while ago that tried to address this
> comprehensively because the trouble is if you just want submodules you have
> to define how our current penta-scheme of access control interacts with
> each level or do away with a few of them to make some simplifying
> assumptions.  It also raises an ambiguity with qualified imports that has
> to be worked out.
>
> On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If I remember correctly it has been said that we don't need namespaces in
> favor of submodules, which schould solve these issues.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> The lack of namespaces is making people create all kinds of "design
> patterns".
>
> struct API {
> static let endpoint = "http://example.com/api;
> }
>
> Here is an "improvement" to the above "design pattern" to prevent
> instantiating API:
>
> struct API {
> private init() {}
> static let endpoint = "http://example.com/api;
> }
>
> Finally, here is another "improvement" that uses enum instead of struct to
> avoid having to write the private initializer:
>
> enum API {
> static let endpoint = "http://example.com/api;
> }
>
> I doubt any of you find this beautiful. Yet these "design patterns" (just
> hacks IMO) are spreading like the plague because of the lack of namespaces.
>
> What do you think?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Warn about unused Optional.some(())

[James Froggatt via swift-evolution]

Would this affect optional chaining? ( a?.voidReturningFunc() also evaluates to 
()? )

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <1fa68175-bc14-4e61-aece-a80b79d55...@apple.com> 


> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Right now, expressions that evaluates to Optional<()>, 
> Optional>… gets special treatment when it’s unused. For example:
> 
> func f(s: String) {}
> let s: String = “”
> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
> and unused.
> 
> func g() throws {}
> try? g() // no warnings here neither.
> 
> This is convenient, but encourages composing map/filter/reduce, etc with 
> side-effect-ful functions, which we have found a few cases of in our 
> production code recently. Granted, these cases could’ve been caught with more 
> careful code reviews. But we wouldn’t have missed them if this “feature” 
> didn’t exist.
> 
> I think we should remove the special treatment so that code in the example 
> above would generate a warning about `()?` being unused. Users can silence it 
> manually by assigning the result to `_`. 
> 
> OTOH, this would undermine the convenience of `try?` when the throwing 
> function don’t return anything.

IMHO, using ‘try?’ to ignore an error result, instead of just turning it into 
an optional, is an anti-pattern, and forcing users to write ‘_ = try? foo()’ 
might not be so bad…

> 
> What do y’all think?
> 
> Daniel Duan
> ___
> 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


- End Message - 



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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jaden Geller via swift-evolution]

Not quite—you can already shadow function names:
```
func f() { print("hi") }
do {
let f = { print("bye") }
f()
}
```

You can refer to shadowed variables within their initial value—function or 
not—within a guard let or if let:
```
func f() -> (() -> ())? { return { print("hi")} }
do {
guard let f = f() else { fatalError() }
f()
}
```

BUT, you cannot refer to shadowed variables within their initial value 
otherwise:
```
func f() { print("hi") }
do {
let f = { f(); f() } // ERROR!!!
f()
}
```

This is inconsistent IMO.

> On Jan 30, 2017, at 5:17 PM, Derrick Ho  wrote:
> 
> The answer is simple, it becomes ambiguous about whether it should get the 
> var or the function pointer
> 
> Suppose we could do this
> 
> let r = 5
> func r() {}
> 
> If we call r, should we get 5 or should we get ()->()
> 
> 
> On Mon, Jan 30, 2017 at 4:21 PM Sean Heber via swift-evolution 
> > wrote:
> I used to believe this was a problem, but once I internalized the idea that 
> this ugliness was a signal to choose better variable and property names, it 
> has ceased to be an issue for me and in fact, IMO, has become an asset of the 
> language.
> 
> l8r
> Sean
> 
> 
> > On Jan 30, 2017, at 3:17 PM, Jaden Geller via swift-evolution 
> > > wrote:
> >
> > I personally find it kind of weird that `let x = 0; do { let x = x + 1 }` 
> > is disallowed but `let x: Int? = 0; if let x = x { }` is allowed. The 
> > former case requires you first rename the variable you plan to shadow, 
> > inconveniently:
> >
> > ```
> > let x = 0
> > do {
> >   let tempX = x // ew
> >   let x = tempX + 1
> > }
> > ```
> >
> >> On Jan 30, 2017, at 11:56 AM, Robert Widmann via swift-evolution 
> >> > wrote:
> >>
> >> This seems like it’s running through the same check that disallows 
> >> defining and calling a closure
> >>
> >> let randomFunc : () -> () = randomFunc()
> >>
> >>> On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution 
> >>> > wrote:
> >>>
> >>> Example that does not compile:
> >>>
> >>>let randomArray = randomArray(withCapacity: 4096)
> >>>
> >>> Compiler error: “Variable used within its own initial value”
> >>> The variable name unfortunately clashes with the function name.
> >>>
> >>> This problem forces the developer to think about an alternative name.
> >>> IMHO that’s suboptimal since many times the most canonical naming would 
> >>> be one where these two go by the same name.
> >>>
> >>> It’s not a big problem in practice but I wonder if there are plans to 
> >>> change this?
> >>>
> >>>
> >>> Thanks,
> >>> Michael Gubik
> >>>
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org 
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >>> 
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org 
> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >> 
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

Re: [swift-evolution] Warn about unused Optional.some(())

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Right now, expressions that evaluates to Optional<()>, 
>> Optional>… gets special treatment when it’s unused. For example:
>> 
>> func f(s: String) {}
>> let s: String = “”
>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
>> and unused.
>> 
>> func g() throws {}
>> try? g() // no warnings here neither.
>> 
>> This is convenient, but encourages composing map/filter/reduce, etc with 
>> side-effect-ful functions, which we have found a few cases of in our 
>> production code recently. Granted, these cases could’ve been caught with 
>> more careful code reviews. But we wouldn’t have missed them if this 
>> “feature” didn’t exist.
>> 
>> I think we should remove the special treatment so that code in the example 
>> above would generate a warning about `()?` being unused. Users can silence 
>> it manually by assigning the result to `_`. 
>> 
>> OTOH, this would undermine the convenience of `try?` when the throwing 
>> function don’t return anything.
> 
> IMHO, using ‘try?’ to ignore an error result, instead of just turning it into 
> an optional, is an anti-pattern, and forcing users to write ‘_ = try? foo()’ 
> might not be so bad…

+1

> 
>> 
>> What do y’all think?
>> 
>> Daniel Duan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] @NSCopying currently does not affect initializers

[Douglas Gregor via swift-evolution]

> On Jan 28, 2017, at 10:43 PM, Rod Brown via swift-evolution 
>  wrote:
> 
> I agree that there is an issue here.
> 
> While I understand that the initialiser avoids the full setter for direct 
> access, I would expect the attribute to mean that the substituted direct 
> access still applied the attribute you marked the API with. I would consider 
> the fact that it doesn't work as a dangerous gap in the API.
> 
> It is also concerning if we consider how this will work with Property 
> Behaviours that are planned for Swift in the future. If we made NSCopying a 
> property behaviour, the direct access would mean it too would not be invoked 
> at initial access so I'm not sure how the best way to get around this is - 
> should we do compiler magic to copy in the initialiser, or should we warn if 
> we don't detect a call to copy() or copy(with:) in the initialiser?

I think we should be doing the compiler magic to call copy(with:) in the 
initializer, because that seems like the most direct way to maintain the 
@NSCopying contract without changing the underlying direct-storage model.

> I think we at least need to do something here. It's a very convoluted piece 
> of logic to say the @NSCopying attribute doesn't work in an initialiser and 
> it's hardly intuitive despite the fair reasoning.

I agree that we need to do something here. It feels like it’s just a bug—that 
this is the only way that @NSCopying makes sense in an attribute. Might even be 
a good starter bug for someone who wants to dip their tows into the type 
checker!

- Doug

> 
> Rod
> 
>> On 29 Jan 2017, at 4:47 pm, Torin Kwok via swift-evolution 
>>  wrote:
>> 
>> Yep, I also admit the design of forbidding calling a setter before full
>> class initialization is reasonable and what's really annoying is the
>> inconsistency.
>> 
>> However, making @NSCopying attribute not subjects to the fact that
>> setters would not be invoked in initializers perhaps is viable too. In
>> the other words, assigning a value to a property whether or not by
>> calling a setter has no influence on whether @NSCopying semantic'd work:
>> copying should always take place after a property has been declared as
>> @NSCopying.
>> 
>> Jean-Daniel writes:
>> 
 Le 28 janv. 2017 à 05:34, Torin Kwok via swift-evolution 
  a écrit :
 
 Hello guys,
 
 Note: This issue has been originally presented inswift-usersmailling list 
 .
  And then I post it again here at the suggestion 
 
  of Jordan Rose:
 
 It might be reasonable to change this behavior, but it probably deserves a 
 bit of discussion on swift-evolution; it's not 100%, for-sure a bug.
 --- the original content follows this line ---
 
 I encountered a strange behavior when I declared a property with the 
 @NSCopying attribute:
 
 // `Person` class inherits from `NSObject` class and conforms to 
 `NSCopying` protocol
 @NSCopying var employee: Person
 and then assigned an external instance of Person class protocol to this 
 property within the designated init methods:
 
 // Designated initializer of `Department` class
 init( employee externalEmployee: Person ) {
 self.employee = externalEmployee
 super.init()
 
 // Assertion would fail since Swift do not actually copy the value 
 assigned to this property 
 // even though `self.employee` has been marked as `@NSCoyping`
 // assert( self.employee !== externalEmployee )
 }
 If I indeed require the deep copying behavior during the init process, 
 instead of taking advantage of @NSCopying attribute, I would have to 
 invoke the copy() method manually:
 
 init( employee externalEmployee: Person ) {
 // ...
 self.employee = externalEmployee.copy() as! Person  
 // ...
 }
 In fact, what really makes me confusing is that @NSCopying semantic does 
 work properly within the other parts of the class definition such as 
 normal instance methods, or external scope. For instance, if we're 
 assigning an external instance of Person to the self.employee proper of 
 Department directly through setter rather than initializer:
 
 department.employee = johnAppleseed
 then self.employee property and johnAppleseed variable will no longer 
 share the same underlying object now. In the other words, @NSCopying 
 attribute makes sense.
 
 After I looked through a great deal of results given by Google, and 
 dicussions on StackOverflow, I finally end up with nothing helpful — the 
 vast majority of articles, documentations as well as issues talking about 
 this similar topics only focus on the basic concepts and 

Re: [swift-evolution] Warn about unused Optional.some(())

[Daniel Duan via swift-evolution]

Not sure if this requires a proposal. The code change is pretty trivial: 
https://github.com/apple/swift/pull/7154 
 .

> On Jan 30, 2017, at 3:25 PM, Slava Pestov  wrote:
> 
>> 
>> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Right now, expressions that evaluates to Optional<()>, 
>> Optional>… gets special treatment when it’s unused. For example:
>> 
>> func f(s: String) {}
>> let s: String = “”
>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
>> and unused.
>> 
>> func g() throws {}
>> try? g() // no warnings here neither.
>> 
>> This is convenient, but encourages composing map/filter/reduce, etc with 
>> side-effect-ful functions, which we have found a few cases of in our 
>> production code recently. Granted, these cases could’ve been caught with 
>> more careful code reviews. But we wouldn’t have missed them if this 
>> “feature” didn’t exist.
>> 
>> I think we should remove the special treatment so that code in the example 
>> above would generate a warning about `()?` being unused. Users can silence 
>> it manually by assigning the result to `_`. 
>> 
>> OTOH, this would undermine the convenience of `try?` when the throwing 
>> function don’t return anything.
> 
> IMHO, using ‘try?’ to ignore an error result, instead of just turning it into 
> an optional, is an anti-pattern, and forcing users to write ‘_ = try? foo()’ 
> might not be so bad…
> 
>> 
>> What do y’all think?
>> 
>> Daniel Duan
>> ___
>> 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] Warn about unused Optional.some(())

[Slava Pestov via swift-evolution]

> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Right now, expressions that evaluates to Optional<()>, 
> Optional>… gets special treatment when it’s unused. For example:
> 
> func f(s: String) {}
> let s: String = “”
> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` 
> and unused.
> 
> func g() throws {}
> try? g() // no warnings here neither.
> 
> This is convenient, but encourages composing map/filter/reduce, etc with 
> side-effect-ful functions, which we have found a few cases of in our 
> production code recently. Granted, these cases could’ve been caught with more 
> careful code reviews. But we wouldn’t have missed them if this “feature” 
> didn’t exist.
> 
> I think we should remove the special treatment so that code in the example 
> above would generate a warning about `()?` being unused. Users can silence it 
> manually by assigning the result to `_`. 
> 
> OTOH, this would undermine the convenience of `try?` when the throwing 
> function don’t return anything.

IMHO, using ‘try?’ to ignore an error result, instead of just turning it into 
an optional, is an anti-pattern, and forcing users to write ‘_ = try? foo()’ 
might not be so bad…

> 
> What do y’all think?
> 
> Daniel Duan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Warn about unused Optional.some(())

[Daniel Duan via swift-evolution]

Hi all,

Right now, expressions that evaluates to Optional<()>, Optional>… 
gets special treatment when it’s unused. For example:

func f(s: String) {}
let s: String = “”
s.map(f) // no warning here, even tho the resulting type is `Optional<()>` and 
unused.

func g() throws {}
try? g() // no warnings here neither.

This is convenient, but encourages composing map/filter/reduce, etc with 
side-effect-ful functions, which we have found a few cases of in our production 
code recently. Granted, these cases could’ve been caught with more careful code 
reviews. But we wouldn’t have missed them if this “feature” didn’t exist.

I think we should remove the special treatment so that code in the example 
above would generate a warning about `()?` being unused. Users can silence it 
manually by assigning the result to `_`. 

OTOH, this would undermine the convenience of `try?` when the throwing function 
don’t return anything.

What do y’all think?

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

Re: [swift-evolution] Initializers

[Joe Groff via swift-evolution]

> On Jan 30, 2017, at 12:36 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> This seems to contradict Swift’s goal of being safe by default, no?  It would 
> make me incredibly uncomfortable if there were a backdoor in DI, even if that 
> backdoor emitted traps when it fails.

There already is a backdoor of sorts. This is one of the intended use cases for 
implicitly-unwrapped optionals. If you don't want to be hassled by DI, declare 
a property as T! type, and it will be implicitly initialized to nil, and trap 
if you try to use it as an unwrapped T without initializing it first.

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

Re: [swift-evolution] Subclass Existentials

[Austin Zheng via swift-evolution]

Given that supporting value subtyping or self-conforming existentials in
the future would not be a code-breaking change AFAICT, I don't think it
makes sense to spend much energy discussing it now. If we do end up getting
value subtyping for Swift 4, we can have a compiler engineer estimate how
much work it would require to support value subtyping constraints on
existentials, and then amend the proposal to loosen the restrictions if the
amount of work makes sense for the Swift 4 timeframe. If no significant
design work is required, it should only take a few days to get a revision
through. A formal proposal might not even be required.

Tangentially, I don't think the type system should be any more complicated
than it needs to be, and I think every addition to the type system needs to
rigorously justify its existence (allowing for clever tricks or a slightly
more elegant representation of a type I don't consider sufficient). It
becomes significantly more difficult to reason about the correctness of
something like a type system as the number of features that interact with
each other increases (c.f. http://io.livecode.ch/learn/namin/unsound).

For this reason, I would be a strong (-1) for allowing `Never`-equivalent
bounds to be defined (at least in this iteration of the proposal). If we do
allow multiple class bounds, the rule should be they must all be part of
the same inheritance chain and that the lowest class on the chain should be
the effective bound. This satisfies the need for typealias composition
without introducing special rules that allow some spellings but not other,
equivalent ones.

Best,
Austin


On Mon, Jan 30, 2017 at 7:42 AM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 29, 2017, at 10:47 PM, Slava Pestov  wrote:
>
>
> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu  wrote:
>
> On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson 
> wrote:
>
>>
>> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu  wrote:
>>
>> On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson 
>>  wrote:
>>
>>>
>>> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu  wrote:
>>>
>>> On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson >> > wrote:
>>>

 On Jan 29, 2017, at 2:25 PM, Xiaodi Wu  wrote:

 On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson  wrote:

>
> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu  wrote:
>
> On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson <
> matt...@anandabits.com> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Cool. Another avenue of improvement here is relaxing the single-class
>> spelling rule for the sake of composing typealiases.
>>
>> As Matthew mentioned, if I have class Base and typealiases Foo = Base
>> & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & Bar.
>>
>> It'd be nice to go one step further: given class Derived : Base, if I
>> have typealiases Foo2 = Base & Protocol1 and Bar2 = Derived & Protocol2,
>> then it could be permitted to write Foo2 & Bar2, since there is 
>> effectively
>> only one subclass requirement (Derived).
>>
>> As I understand it, the rationale for allowing only one subclass
>> requirement is that Swift supports only single inheritance. Thus, two
>> disparate subclass requirements Base1 & Base2 would make your existential
>> type essentially equivalent to Never. But Base1 & Base1 & Base1 is fine 
>> for
>> the type system, the implementation burden (though greater) shouldn't be
>> too awful, and you would measurably improve composition of typealiases.
>>
>>
>> Yes, this is what I was indicating in my post as well.
>>
>> Are you suggesting that Base1 & Base2 compose to a type that is
>> treated identically to Never do you think it should be an immediate
>> compiler error?  I remember having some discussion about this last year 
>> and
>> think somebody came up with a very interesting example of where the 
>> former
>> might be useful.
>>
>
> Last year's discussion totally eludes me for some reason. But sure, if
> deferring the error until runtime is actually useful then why not? In the
> absence of an interesting use case, though, I think it'd be nice for the
> compiler to warn you that Base1 & Base2 is not going to be what you want.
>
>
> Deferring to runtime isn’t what I mean.  If you try to actually *do*
> anything that requires an instance of `Base1 & Based` (which you almost
> always would) 

Re: [swift-evolution] Strings in Swift 4

[Jaden Geller via swift-evolution]

> On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Why should that be out-of-bounds?  Whether it is out-of-bounds would
> depend on what items is.  If it's an array, that should be equivalent to
> 
>   let x = items[items.startIndex..

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Sean Heber via swift-evolution]

I used to believe this was a problem, but once I internalized the idea that 
this ugliness was a signal to choose better variable and property names, it has 
ceased to be an issue for me and in fact, IMO, has become an asset of the 
language.

l8r
Sean


> On Jan 30, 2017, at 3:17 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> I personally find it kind of weird that `let x = 0; do { let x = x + 1 }` is 
> disallowed but `let x: Int? = 0; if let x = x { }` is allowed. The former 
> case requires you first rename the variable you plan to shadow, 
> inconveniently:
> 
> ```
> let x = 0
> do {
>   let tempX = x // ew
>   let x = tempX + 1
> }
> ```
> 
>> On Jan 30, 2017, at 11:56 AM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> This seems like it’s running through the same check that disallows defining 
>> and calling a closure 
>> 
>> let randomFunc : () -> () = randomFunc()
>> 
>>> On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution 
>>>  wrote:
>>> 
>>> Example that does not compile:
>>> 
>>>let randomArray = randomArray(withCapacity: 4096)
>>> 
>>> Compiler error: “Variable used within its own initial value”
>>> The variable name unfortunately clashes with the function name.
>>> 
>>> This problem forces the developer to think about an alternative name.
>>> IMHO that’s suboptimal since many times the most canonical naming would be 
>>> one where these two go by the same name.
>>> 
>>> It’s not a big problem in practice but I wonder if there are plans to 
>>> change this?
>>> 
>>> 
>>> Thanks,
>>> Michael Gubik
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Initializers

[Jaden Geller via swift-evolution]

It seems to me that A should provide an `init(x: Int = 1) { self.x = x }` 
initializer in such case so B may call `super.init(x: 2)`. This initializer 
could even be made internal if necessary, but it honestly seems weird for a 
superclass to default initialize to a certain value and a subclass to default 
initialize to another.

Regardless, I definitely don’t think introducing unsafely is the right choice. 
If anything, there ought to be a compiler optimization (if there isn’t one 
already) that’ll eliminate these duplicate assignments—and I would bet there is 
if `super.init()` can be inlined.

> On Jan 28, 2017, at 10:07 AM, Victor Petrescu via swift-evolution 
>  wrote:
> 
> Hello,
> 
> My name is Victor, been a developer (C, delphi, php, java, js) for the last 
> 10 years or so and lately I had the chance to try swift. I have a 
> suggestion/question regarding initializers.
> 
> Sidenote: If this is not the correct mailing list for this can you please 
> redirect me to the right place?
> 
> Consider the following 2 classes and code:
> 
> class A {
>  var x:Int
> 
>  init() {
>  x = 1
>  }
> }
> 
> class B : A {
> override init() {
>  super.init() // Swift FORCES this call
>  x = 2
> }
> }
> 
> var a:B
> for i in 0... {
> a = B()  // Whatever... some code that inits B.
> }
> 
> This results in  x = 1 then  x = 2... the x = 1 being totally 
> useless in this particular case.
> 
> In this case, if you don't make the super init you get a compile error.
> 
> Now... I see the use of this. It ensure that all members are initialized. For 
> example if A had a private variable (another strange choice here with what 
> private means in swift but I haven't thought on it yet so... maybe is a cool 
> choice), the B init could not initialize it. I also understand that the cases 
> when you need this minor performance gain are rather rare (but they do still 
> exist). So I guess the choice for the super.init() had that reasoning.
> 
> Still... my suggestion would be to give a warning, maybe force a key word 
> before the init (like iKnowWhatImDoing init() {}), THEN in case vars are 
> still not inited give a runtime error (afaik Objective C for example gives a 
> warning). That ensures everything is ok and also allows programmers that have 
> strange cases to treat them accordingly.
> 
> Anyway... that would be my suggestion. Maybe this was discussed before 
> also... If this was discussed before can you please point me to the 
> discussion? I like to understand the choices for the tools I use.
> 
> 
> P.S. Please excuse any grammatical errors... English is not my first language.
> 
> Thank you for your time and have a great day,
> Petrescu Victor
> ___
> 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] Why doesn't Swift allow a variable and a function with the same name?

[Jaden Geller via swift-evolution]

I personally find it kind of weird that `let x = 0; do { let x = x + 1 }` is 
disallowed but `let x: Int? = 0; if let x = x { }` is allowed. The former case 
requires you first rename the variable you plan to shadow, inconveniently:

```
let x = 0
do {
  let tempX = x // ew
  let x = tempX + 1
}
```

> On Jan 30, 2017, at 11:56 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> This seems like it’s running through the same check that disallows defining 
> and calling a closure 
> 
> let randomFunc : () -> () = randomFunc()
> 
>> On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution 
>> > wrote:
>> 
>> Example that does not compile:
>> 
>>let randomArray = randomArray(withCapacity: 4096)
>> 
>> Compiler error: “Variable used within its own initial value”
>> The variable name unfortunately clashes with the function name.
>> 
>> This problem forces the developer to think about an alternative name.
>> IMHO that’s suboptimal since many times the most canonical naming would be 
>> one where these two go by the same name.
>> 
>> It’s not a big problem in practice but I wonder if there are plans to change 
>> this?
>> 
>> 
>> Thanks,
>> Michael Gubik
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0150 Package Manager Support for branches

[T.J. Usiyan via swift-evolution]

  • What is your evaluation of the proposal?
+ 1
• Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
• Does this proposal fit well with the feel and direction of Swift?
Yes
• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Yes. It's about the same.
• 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
A quick read.

On Mon, Jan 30, 2017 at 3:41 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 24, 2017, at 10:18 AM, Daniel Dunbar 
> wrote:
> >
> > Hello Swift community,
> >
> > The review of SE-0150 “ Package Manager Support for branches" begins now
> and runs through January 31, 2017. The proposal is available here:
> >
> >  https://github.com/apple/swift-evolution/blob/master/
> proposals/0150-package-manager-branch-support.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-build-dev and swift-evolution mailing
> lists at
> >  https://lists.swift.org/mailman/listinfo/swift-build-dev
> >  https://lists.swift.org/mailman/listinfo/swift-evolution
> > or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
> >  https://github.com/apple/swift-evolution/blob/master/
> proposals/0150-package-manager-branch-support.md
> >
> > 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?
> +1
> I would even go a bit further and suggest that "Package(url: String,
> branch: String)” should have “master” be the default value for `branch`, to
> make it simpler for small developer teams who don’t necessarily have all
> the collaboration issues of large projects.
>
> >   • Is the problem being addressed significant enough to warrant a
> change to Swift?
> IMHO, yes. Particularly since Xcode doesn’t support git tags (that I can
> find, anyway)
>
> >   • Does this proposal fit well with the feel and direction of Swift?
> IMOH, yes. This proposal will make development with much easier for
> programmers whose work-flow is branch-based rather than tag-based.
>
> >   • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> An embarrassingly long time trying to figure out why a package wasn’t
> seeing changes I’d committed to one of its dependencies... Somewhere along
> the line I must’ve accidentally created a branch called “1.0.0”, which lead
> to me conflating the 1.0.0 tag with the 1.0.0 branch, which has caused me
> no end of head scratching.
>
> - Dave Sweeris
> ___
> 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] Initializers

[David Sweeris via swift-evolution]

> On Jan 30, 2017, at 12:36 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> This seems to contradict Swift’s goal of being safe by default 
> , no?

IIUC, it wouldn’t contradict that goal if the compiler could guarantee that 
everything still gets initialized. I don’t know how that would work with 
classes that have private/fileprivate properties, though. If you’re subclassing 
something from the same project, the compiler could just look, but seeing as 
how exposing those things would kinda defeat the purpose, I don’t think there’s 
an existing mechanism for it to check 3rd party classes. Maybe we could add a 
flag to classes’ binary format indicating whether it’s possible for the 
compiler to infer if super.init() can be safely skipped?

I don’t have a opinion yet on whether this proposal is a good idea… I’m just 
commenting on (my understanding of) Swift’s safety goals.

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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Austin Zheng via swift-evolution]

The reason Swift works like this is because you can assign a function value
(independently of calling it) to a variable. So there aren't two separate
namespaces separating function names and variable names.

To wit:

func randomArray(withCapacity capacity: Int) -> [Int] {
// 
}

// An array of Ints, the result of calling the function.
let myValue : [Int] = randomArray(withCapacity: 10)
// A function, of type Int -> Array.
let myFunc : ((Int) -> [Int]) = randomArray

Best,
Austin




On Mon, Jan 30, 2017 at 11:37 AM, Michael Gubik via swift-evolution <
swift-evolution@swift.org> wrote:

> Example that does not compile:
>
> let randomArray = randomArray(withCapacity: 4096)
>
> Compiler error: “Variable used within its own initial value”
> The variable name unfortunately clashes with the function name.
>
> This problem forces the developer to think about an alternative name.
> IMHO that’s suboptimal since many times the most canonical naming would be
> one where these two go by the same name.
>
> It’s not a big problem in practice but I wonder if there are plans to
> change this?
>
>
> Thanks,
> Michael Gubik
>
> ___
> 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] Annotation of Warnings/Errors

[Jeremy Pereira via swift-evolution]

> On 26 Jan 2017, at 20:45, charles--- via swift-evolution 
>  wrote:
> 
> +1
> 
> Strongly in favour of this one. One of those things that seems obvious in 
> retrospect
> 
> It would also make the language more enjoyable to code in.

For you maybe. I like having the issues pop up and then disappear when I’m done 
with the thing they are complaining about. For example, the issue that tells me 
that some var I have declared is never mutated is a nice little prompt that I 
haven’t finished the scope yet.


> When Xcode nags me about my function not providing a return value when I've 
> only just started writing it, I get the irrational urge to tell Xcode to shut 
> its (metaphorical) mouth.

Go to preferences and select the “General” tab. Make sure that “show live 
issues” is deselected. That tells Xcode to shut up. If beginners are really so 
confused about the errors popping up (I’m sceptical), maybe that should be 
lesson one.

I would be dead against any language change that assumes a particular IDE or a 
particular workflow on the part of all developers.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0150 Package Manager Support for branches

[David Sweeris via swift-evolution]

> On Jan 24, 2017, at 10:18 AM, Daniel Dunbar  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0150 “ Package Manager Support for branches" begins now and 
> runs through January 31, 2017. The proposal is available here:
> 
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>  https://lists.swift.org/mailman/listinfo/swift-build-dev
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> 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?
+1
I would even go a bit further and suggest that "Package(url: String, branch: 
String)” should have “master” be the default value for `branch`, to make it 
simpler for small developer teams who don’t necessarily have all the 
collaboration issues of large projects.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
IMHO, yes. Particularly since Xcode doesn’t support git tags (that I can find, 
anyway)

>   • Does this proposal fit well with the feel and direction of Swift?
IMOH, yes. This proposal will make development with much easier for programmers 
whose work-flow is branch-based rather than tag-based.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
An embarrassingly long time trying to figure out why a package wasn’t seeing 
changes I’d committed to one of its dependencies... Somewhere along the line I 
must’ve accidentally created a branch called “1.0.0”, which lead to me 
conflating the 1.0.0 tag with the 1.0.0 branch, which has caused me no end of 
head scratching.

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

Re: [swift-evolution] Initializers

[Robert Widmann via swift-evolution]

This seems to contradict Swift’s goal of being safe by default 
, no?  It would make me incredibly uncomfortable if 
there were a backdoor in DI, even if that backdoor emitted traps when it fails.

> On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution 
>  wrote:
> 
> Hello,
> 
> My name is Victor, been a developer (C, delphi, php, java, js) for the last 
> 10 years or so and lately I had the chance to try swift. I have a 
> suggestion/question regarding initializers.
> 
> Sidenote: If this is not the correct mailing list for this can you please 
> redirect me to the right place?
> 
> Consider the following 2 classes and code:
> 
> class A {
>  var x:Int
> 
>  init() {
>  x = 1
>  }
> }
> 
> class B : A {
> override init() {
>  super.init() // Swift FORCES this call
>  x = 2
> }
> }
> 
> var a:B
> for i in 0... {
> a = B()  // Whatever... some code that inits B.
> }
> 
> This results in  x = 1 then  x = 2... the x = 1 being totally 
> useless in this particular case.
> 
> In this case, if you don't make the super init you get a compile error.
> 
> Now... I see the use of this. It ensure that all members are initialized. For 
> example if A had a private variable (another strange choice here with what 
> private means in swift but I haven't thought on it yet so... maybe is a cool 
> choice), the B init could not initialize it. I also understand that the cases 
> when you need this minor performance gain are rather rare (but they do still 
> exist). So I guess the choice for the super.init() had that reasoning.
> 
> Still... my suggestion would be to give a warning, maybe force a key word 
> before the init (like iKnowWhatImDoing init() {}), THEN in case vars are 
> still not inited give a runtime error (afaik Objective C for example gives a 
> warning). That ensures everything is ok and also allows programmers that have 
> strange cases to treat them accordingly.
> 
> Anyway... that would be my suggestion. Maybe this was discussed before 
> also... If this was discussed before can you please point me to the 
> discussion? I like to understand the choices for the tools I use.
> 
> 
> P.S. Please excuse any grammatical errors... English is not my first language.
> 
> Thank you for your time and have a great day,
> Petrescu Victor
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Initializers

[Victor Petrescu via swift-evolution]

Hello,

My name is Victor, been a developer (C, delphi, php, java, js) for the last
10 years or so and lately I had the chance to try swift. I have a
suggestion/question regarding initializers.

Sidenote: If this is not the correct mailing list for this can you please
redirect me to the right place?

Consider the following 2 classes and code:

class A {
 var x:Int

 init() {
 x = 1
 }
}

class B : A {
override init() {
 super.init() // Swift FORCES this call
 x = 2
}
}

var a:B
for i in 0... {
a = B()  // Whatever... some code that inits B.
}

This results in  x = 1 then  x = 2... the x = 1 being
totally useless in this particular case.

In this case, if you don't make the super init you get a compile error.



*Now... I see the use of this. It ensure that all members are initialized.
For example if A had a private variable (another strange choice here with
what private means in swift but I haven't thought on it yet so... maybe is
a cool choice), the B init could not initialize it. I also understand that
the cases when you need this minor performance gain are rather rare (but
they do still exist). So I guess the choice for the super.init() had that
reasoning.*
Still... my suggestion would be to give a warning, maybe force a key word
before the init (like iKnowWhatImDoing init() {}), THEN in case vars are
still not inited give a runtime error (afaik Objective C for example gives
a warning). That ensures everything is ok and also allows programmers that
have strange cases to treat them accordingly.

Anyway... that would be my suggestion. Maybe this was discussed before
also... If this was discussed before can you please point me to the
discussion? I like to understand the choices for the tools I use.


P.S. Please excuse any grammatical errors... English is not my first
language.

Thank you for your time and have a great day,
Petrescu Victor
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The lack of namespaces is leading people astray

[Robert Widmann via swift-evolution]

I submitted a proposal with TJ a while ago that tried to address this 
comprehensively because the trouble is if you just want submodules you have to 
define how our current penta-scheme of access control interacts with each level 
or do away with a few of them to make some simplifying assumptions.  It also 
raises an ambiguity with qualified imports that has to be worked out.

> On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> If I remember correctly it has been said that we don't need namespaces in 
> favor of submodules, which schould solve these issues.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> The lack of namespaces is making people create all kinds of "design 
>> patterns".
>> 
>> struct API {
>> static let endpoint = "http://example.com/api "
>> }
>> 
>> Here is an "improvement" to the above "design pattern" to prevent 
>> instantiating API:
>> 
>> struct API {
>> private init() {}
>> static let endpoint = "http://example.com/api "
>> }
>> 
>> Finally, here is another "improvement" that uses enum instead of struct to 
>> avoid having to write the private initializer:
>> 
>> enum API {
>> static let endpoint = "http://example.com/api "
>> }
>> 
>> I doubt any of you find this beautiful. Yet these "design patterns" (just 
>> hacks IMO) are spreading like the plague because of the lack of namespaces.
>> 
>> What do you think?
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

[Robert Widmann via swift-evolution]

> On Jan 30, 2017, at 2:38 PM, Ankit Agarwal  wrote:
> 
> 
> Not in practice (with respect to package manifests). In fact, it seems that, 
> given there are separate commands (swift build and swift test), separate 
> directories (Sources and Tests), and separate products, that there's a hole 
> to be filled here by separate handling for test suites in package manifests.
> 
> FWIW, overriding conventions will potentially allow you control the layout of 
> the package (when we have that feature).

In that case, as long as there are plans for this kind of feature, I can hold 
off on submitting this proposal until it materializes.

>  
>  
> This is all not to discount the features you've brought up as well, but I'm 
> having trouble seeing why a distinction here is such a problem.
> 
> Could you elaborate on what kind of distinction are you proposing? Is it 
> separating targets and testTargets?

Yes.

> 
> -- 
> Ankit
> 

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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Sun Jan 22 2017, James Froggatt  wrote:

> Could we add subscript labels to the list of options? While keeping
> the range syntax is appealing, I'm concerned it may cause confusion if
> the operators are used out of context.
>
> The wording is up for debate, but something like this should be a fair 
> alternative:
> items[from: i]
> items[upTo: i]
>
> Sorry if this has been covered elsewhere (can't find the answer in
> this thread), but my first questions on discovering these operators
> (my source of confusion) would be what happens if I try the following:
> let partialRange = 0..< //is this an infinite range?

If we implemented that syntax, it would be.  The proposal is that
half-open ranges without an upper bound would be illegal, but

  let partialRange = 0...

is just such an infinite range, which is useful in its own right.  For
example, let's deprecate enumerated():

   for (i, e) in zip(0..., elements) {
 print("\(i): \(e)")
   }

> let x = items[partialRange] //shouldn't this cause an out of bounds error?

Why should that be out-of-bounds?  Whether it is out-of-bounds would
depend on what items is.  If it's an array, that should be equivalent to

   let x = items[items.startIndex..

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Robert Widmann via swift-evolution]

This seems like it’s running through the same check that disallows defining and 
calling a closure 

let randomFunc : () -> () = randomFunc()

> On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution 
>  wrote:
> 
> Example that does not compile:
> 
>let randomArray = randomArray(withCapacity: 4096)
> 
> Compiler error: “Variable used within its own initial value”
> The variable name unfortunately clashes with the function name.
> 
> This problem forces the developer to think about an alternative name.
> IMHO that’s suboptimal since many times the most canonical naming would be 
> one where these two go by the same name.
> 
> It’s not a big problem in practice but I wonder if there are plans to change 
> this?
> 
> 
> Thanks,
> Michael Gubik
> 
> ___
> 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] protocol-oriented integers (take 2)

[Max Moiseev via swift-evolution]

> On Jan 30, 2017, at 12:21 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jan 29, 2017, at 10:07 PM, Dave Abrahams  wrote:
>> 
> It might make a great deal of sense to support bitwise operations on
> this type, 
 
 I think that's a model of SetAlgebra, then, isn't it?
>>> 
>>> Hmm, arguably. It's a shame that we won't be able to use it with
>>> things like `OptionSet`, though.
>> 
>> Why not?  That conforms to SetAlgebra.
> 
> I mean that `OptionSet.RawValue` currently has to conform to 
> `BitwiseOperations`, but would now need to conform to `BinaryInteger` (or a 
> sub-protocol).
It is not a protocol requirement, just a way for the standard library to 
provide a default implementation.
BitwiseOperations was replaced by the FixedWidthInteger in the prototype for 
this case.

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

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

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Jacob Bandes-Storch via swift-evolution]

Suppose it were allowed. What should this do?

let something = randomArray

On Mon, Jan 30, 2017 at 11:37 AM, Michael Gubik via swift-evolution <
swift-evolution@swift.org> wrote:

> Example that does not compile:
>
> let randomArray = randomArray(withCapacity: 4096)
>
> Compiler error: “Variable used within its own initial value”
> The variable name unfortunately clashes with the function name.
>
> This problem forces the developer to think about an alternative name.
> IMHO that’s suboptimal since many times the most canonical naming would be
> one where these two go by the same name.
>
> It’s not a big problem in practice but I wonder if there are plans to
> change this?
>
>
> Thanks,
> Michael Gubik
>
> ___
> 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] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Mon Jan 30 2017, Nate Cook  wrote:

>> On Jan 30, 2017, at 8:51 AM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>>> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution 
>>> :
>>> 
>>> Could we add subscript labels to the list of options? While keeping
>
>>> the range syntax is appealing, I'm concerned it may cause confusion
>>> if the operators are used out of context.
>> 
>> Good point!
>> 
>>> The wording is up for debate, but something like this should be a fair 
>>> alternative:
>>> items[from: i]
>>> items[upTo: i]
>> 
>> For me that's at least as readable as the range syntax.
>> 
>>> 
>>> Sorry if this has been covered elsewhere (can't find the answer in
>>> this thread), but my first questions on discovering these operators
>>> (my source of confusion) would be what happens if I try the
>>> following:
>>> let partialRange = 0..< //is this an infinite range?
>>> let x = items[partialRange] //shouldn't this cause an out of bounds error?
>> 
>> Good point! Probably this shouldn't be allowed, making the literal
>> range syntax with open ends tied into the subscript which is a bit
>> confusing indeed.
>
> `partialRange` here is an incomplete range, not an infinite one. 
> When you use an incomplete range to subscript a collection, the
> collection "completes" it by filling in the start or end index as
> required. You can see more about the details of incomplete ranges in
> this proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>
> One other aspect of incomplete ranges that I haven't seen discussed
> (though I may have missed it) is how they work inpattern matching. It
> would be nice to use incomplete ranges in switch statements, so that
> instead of:
>
> switch x {
> case let y where y < 0: print("< 0")
> case 0...10: print("0-10")
> case let y where y > 10: print("> 10")
> default: print("wat")
> }
>
> we could write:
>
> switch x {
> case ..<0: print("< 0")
> case 0...10: print("0-10")
> case 10...: print("> 10")
> default: print("wat")
> }

That's interesting!

> To me, that implies that we'll want a postfix ... operator to exist,
> though I agree it's not clear what it should do in a subscript. Are
> there contexts in which we would want i... and i..< to do different
> things?

AFAICT no, so there's no reason to support both.

-- 
-Dave

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

Re: [swift-evolution] protocol-oriented integers (take 2)

[Max Moiseev via swift-evolution]

> On Jan 29, 2017, at 4:41 AM, Xiaodi Wu  wrote:
> 
>  
> >   static func doubleWidthMultiply(_ lhs: Self, _ rhs: Self) -> (high: Self, 
> > low: Magnitude)
> >   static func doubleWidthDivide(_ lhs: (high: Self, low: Magnitude), _ rhs: 
> > Self) -> (quotient: Self, remainder: Self)
> 
> Could these take/return a single `DoubleWidth` value instead of two 
> separate `Self` and `Magnitude` values? Or would that present circularity 
> problems?
> 
> Having mulled the idea of implementing an IEEE Decimal type, I'd be sad to 
> see these return DoubleWidth. Double-width multiply as it is here is 
> useful when you want to get the result and immediately discard either the 
> high or the low bits, for instance. If you'd want a result of type 
> `DoubleWidth` instead, you could always just write `DoubleWidth(a) 
> * DoubleWidth(b)`.

doubleWidthDivide should not return a DoubleWidth for two reasons:
1. The components of it’s return type are not high and low, but are quotient 
and remainder instead.
2. In DoubleWidth high is T and low is T.Magnitude, which is not the case 
for quotient and remainder.

Having said that, there is a solution for doubleWidthMultiply, that I think is 
worth trying:

enum DoubleWidth {
  case .parts(high: T, low: T.Magnitude)

  var high: T { switch self { case .parts(let high, _): return high } }
  var low: T.Magnitude { switch self { case .parts(_, let low): return low } }
}

This way it will be possible to both do pattern-matching on the result of 
doubleWidthMultiply, and use it as a whole, accessing r.high and r.low when 
needed.

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

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

[Ankit Agarwal via swift-evolution]

> Not in practice (with respect to package manifests). In fact, it seems
> that, given there are separate commands (swift build and swift test),
> separate directories (Sources and Tests), and separate products, that
> there's a hole to be filled here by separate handling for test suites in
> package manifests.
>

FWIW, overriding conventions will potentially allow you control the layout
of the package (when we have that feature).


>
>
This is all not to discount the features you've brought up as well, but I'm
> having trouble seeing why a distinction here is such a problem.
>

Could you elaborate on what kind of distinction are you proposing? Is it
separating targets and testTargets?

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

[swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Michael Gubik via swift-evolution]

Example that does not compile:

let randomArray = randomArray(withCapacity: 4096)

Compiler error: “Variable used within its own initial value”
The variable name unfortunately clashes with the function name.

This problem forces the developer to think about an alternative name.
IMHO that’s suboptimal since many times the most canonical naming would be one 
where these two go by the same name.

It’s not a big problem in practice but I wonder if there are plans to change 
this?


Thanks,
Michael Gubik

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

Re: [swift-evolution] protocol-oriented integers (take 2)

[Dave Abrahams via swift-evolution]

on Mon Jan 30 2017, Brent Royal-Gordon  wrote:

>> On Jan 29, 2017, at 10:07 PM, Dave Abrahams  wrote:
>> 
> It might make a great deal of sense to support bitwise operations on
> this type, 
 
 I think that's a model of SetAlgebra, then, isn't it?
>>> 
>>> Hmm, arguably. It's a shame that we won't be able to use it with
>>> things like `OptionSet`, though.
>> 
>> Why not?  That conforms to SetAlgebra.
>
> I mean that `OptionSet.RawValue` currently has to conform to
> `BitwiseOperations`, 

Actually it doesn't.  You just have to implement these yourself in that
case:

  extension OptionSet where Self.RawValue : BitwiseOperations {
convenience init()
mutating func formUnion(_ other: Self)
mutating func formIntersection(_ other: Self)
mutating func formSymmetricDifference(_ other: Self)
  }

> but would now need to conform to `BinaryInteger` (or a sub-protocol).

Does that limit you in some useful way?

-- 
-Dave

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

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

[Nate Cook via swift-evolution]

> On Jan 30, 2017, at 2:47 AM, Alexey Komnin via swift-evolution 
>  wrote:
> 
> Hello to everyone.
> 
> Let me put my two cents.
> 
>>> I didn’t want the SortedArray to conform to MutableCollection or
>>> even RandomAccessCollection as I felt it was not needed just to
>>> support binary search and prevent re-sorting.
>> 
>> You are right not to support MutableCollection or
>> RangeReplaceableCollection, as those would allow you to violate the
>> “sorted” invariant.  However, it should conform to
>> RandomAccessCollection; that's really easy to implement and would
>> improve ease-of-use a lot.
> 
> Are we able to add some kind of type constraint which allows
> append/prepend operations on a particular collection? Seems like a
> good replacement for MutableCollection in this case. It should be
> available to append elements greater or equal to the last element in
> SortedArray, isn't it?

I've been playing around with a protocol-based approach to these questions. A 
mutable sorted collection can easily allow operations that maintain the 
collection's order (basically just insertion with the collection deciding where 
to put the element or elements and removal of one or more elements). I suppose 
it's possible to allow appending / prepending if we require that the elements 
be (a) sorted and (b) wouldn't change the sort of the collection.

You can see my current version here: 
https://gist.github.com/natecook1000/9400edd75947fcf41dd4c82d1519dea8 — it 
defines two protocols along with a mutable SortedArray and an immutable 
SortedView.

-Nate


> Regards,
> Alex Komnin.
> 
> 
> 
> On Mon, Jan 30, 2017 at 3:21 AM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> Hi Cihat,
>> 
>> Thanks for diving in here!  For reference, here's the last thing I said
>> about this topic (IIRC):
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016729.html
>> 
>> Also
>> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift.gyb#L679
>> 
>> Note: the comment there isn't quite right: 
>> 
>> 
>> on Sun Jan 29 2017, Cihat Gündüz  wrote:
>> 
>>> Hi guys, I know this topic is probably out of scope for Swift 4
>>> and a proposal was already rejected for Swift 3, but I’d like to share
>>> my two cents on this as I just wrote a SortedArray class with support
>>> for binary search in my open source library HandySwift.
>>> 
>>> You can see my classes current implementation here:
>>> https://github.com/Flinesoft/HandySwift/blob/cd7ae7041c8174cd655f24eae653f76697875a48/Sources/Structs/SortedArray.swift
>>> 
>>> My goal was to provide only what is commonly needed when working with
>>> big arrays in algorithms. For me this included:
>>> 
>>> - having a type that keeps a sorted array to prevent re-sorting (solution: 
>>> the SortedArray class)
>> 
>> Sounds consistent with my feedback... but it doesn't conform to
>> RandomAccessCollection.  Why not?
>> 
>>> - have a method that can find an object using binary search (solution: the 
>>> index method)
>> 
>> Please see the algorithms prototype
>> 
>>> - allow partitioning the array into smaller parts (solution: subscript, 
>>> prefix & suffix methods)
>> 
>> * The collection returned by the slicing subscript should obey the law
>> 
>> a[i..> 
>>  Normally that means you want to make it a different type from a.
>> 
>>> - prevent re-implementing the Array class (solution: a getter to the
>>>  stored internal array)
>> 
>> Not sure I understand what this is supposed to mean.
>> 
>>> Also note that the SortedArray in my approach allows all types that
>>> conform to `Sequence` as input with `Comparable` elements and saves
>>> them into a sorted array on initialization. That array is also
>>> publicly read-accessible. Inserting and deleting objects from the
>>> SortedArray are possible, too, but that’s just few of the
>>> MutableCollection methods.
>> 
>> Actually no, those are RangeReplaceableCollection methods.
>> 
>>> I didn’t want the SortedArray to conform to MutableCollection or
>>> even RandomAccessCollection as I felt it was not needed just to
>>> support binary search and prevent re-sorting.
>> 
>> You are right not to support MutableCollection or
>> RangeReplaceableCollection, as those would allow you to violate the
>> “sorted” invariant.  However, it should conform to
>> RandomAccessCollection; that's really easy to implement and would
>> improve ease-of-use a lot.
>> 
>> 
>>> Maybe my approach can somehow help forming the final solution to be
>>> included into Swift once this features is tackled again.
>>> 
>>> Best regards,
>>> Cihat
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> --
>> -Dave
>> 
>> ___
>> 

Re: [swift-evolution] Strings in Swift 4

[Nevin Brackett-Rozinsky via swift-evolution]

>
> Are there contexts in which we would want i... and i..< to do different
> things?


I posit that in the context of incomplete ranges, we always want “i...” to
mean “greater than or equal to i”, and we do not want “i..<” to mean
anything.

We may, however, want something like “i<..” to mean “strictly greater than
i”, though I’m not sure how it should be spelled.

Nevin


On Mon, Jan 30, 2017 at 12:31 PM, Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 30, 2017, at 8:51 AM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution <
> swift-evolution@swift.org>:
> >>
> >> Could we add subscript labels to the list of options? While keeping the
> range syntax is appealing, I'm concerned it may cause confusion if the
> operators are used out of context.
> >
> > Good point!
> >
> >> The wording is up for debate, but something like this should be a fair
> alternative:
> >> items[from: i]
> >> items[upTo: i]
> >
> > For me that's at least as readable as the range syntax.
> >
> >>
> >> Sorry if this has been covered elsewhere (can't find the answer in this
> thread), but my first questions on discovering these operators (my source
> of confusion) would be what happens if I try the following:
> >> let partialRange = 0..< //is this an infinite range?
> >> let x = items[partialRange] //shouldn't this cause an out of bounds
> error?
> >
> > Good point! Probably this shouldn't be allowed, making the literal range
> syntax with open ends tied into the subscript which is a bit confusing
> indeed.
>
> `partialRange` here is an incomplete range, not an infinite one. When you
> use an incomplete range to subscript a collection, the collection
> "completes" it by filling in the start or end index as required. You can
> see more about the details of incomplete ranges in this proposal:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0132-sequence-end-ops.md
>
> One other aspect of incomplete ranges that I haven't seen discussed
> (though I may have missed it) is how they work inpattern matching. It would
> be nice to use incomplete ranges in switch statements, so that instead of:
>
> switch x {
> case let y where y < 0: print("< 0")
> case 0...10: print("0-10")
> case let y where y > 10: print("> 10")
> default: print("wat")
> }
>
> we could write:
>
> switch x {
> case ..<0: print("< 0")
> case 0...10: print("0-10")
> case 10...: print("> 10")
> default: print("wat")
> }
>
> To me, that implies that we'll want a postfix ... operator to exist,
> though I agree it's not clear what it should do in a subscript. Are there
> contexts in which we would want i... and i..< to do different things?
>
> Nate
>
> ___
> 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] [Draft] Test-Only Package Dependencies and Targets

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/01/26 4:11、Ankit Agarwal  のメッセージ:

> 
> 
>> On Thu, Jan 26, 2017 at 1:55 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> Three parts for three points:
>> 
>> 1) Thanks!
>> 
>> 2) I'm not sure generalizing this is particularly useful post-products.  The 
>> larger point is not to have non-exported/local target dependencies but to 
>> make clear the divide between a package and its test suite in the manifest 
>> as well as on disk.  Local dependencies seem like a separate proposal 
>> entirely.
> 
> We do have a clear divide between normal modules and test modules. 
> I am not sure adding a special case test dependencies makes sense right now. 
> We might end up having conditional dependencies later w.r.t platform and 
> other parameters.
> 

Not in practice (with respect to package manifests). In fact, it seems that, 
given there are separate commands (swift build and swift test), separate 
directories (Sources and Tests), and separate products, that there's a hole to 
be filled here by separate handling for test suites in package manifests.

This is all not to discount the features you've brought up as well, but I'm 
having trouble seeing why a distinction here is such a problem.

> Daniel, do you want to pitch in? 
> 
>> 3) Wow, I honestly should have noticed this: I took the time to peruse the 
>> source for the help text and still managed to miss it.  It has been struck 
>> from the gist of this proposal.
>> 
>> ~Robert Widmann
>> 
>> 2017/01/25 3:07、Ankit Aggarwal  のメッセージ:
>> 
>>> 
 On 25-Jan-2017, at 4:02 AM, Robert Widmann via swift-evolution 
  wrote:
 
 Hello Swift Community,
 
 Harlan Haskins and I have been working on libraries to make interacting 
 with LLVM and Clang’s APIs more elegant with native Swift interfaces.  
 While writing up the packages we realized the package manager wouldn’t 
 allow us to specify testing targets and test-only dependencies.  To 
 rectify that, I have attached a draft proposal for adding test-only 
 targets and dependency fields to the Swift Package manager.  This proposal 
 can also be read in gist form.
 
 Cheers,
 
 ~Robert Widmann
 
>>> 
>>> Thanks for driving this! It is a very desirable feature which needs 
>>> proposal work. Comments inline.
>>> 
>>> 
>>> 
 Test-Only Package Dependencies and Targets
 Proposal: SE-
 Authors: Harlan Haskins, Robert Widmann
 Review Manager: TBD
 Status: Awaiting review
 Introduction
 
 This proposal reinstates Swift package manager’s ability to fetch 
 dependencies and build targets scoped exclusively to the testing module(s) 
 of a given package.
 
 Swift-evolution thread: Discussion thread topic for that proposal
 
 Motivation
 
 Soon after SE-0019 identified the need for richer test-only dependencies 
 and targets, a decision was made to remove the package manager’s fledgling 
 ability to treat certain dependencies as test-only. This has led to a 
 myriad of clever-but-needlessly-complex workarounds ([1], [2], [3]) on the 
 part of 3rd parties to recover the feature themselves. In addition, the 
 Swift community has come up with a number of their own frameworks to 
 augment functionality in XCTest but depending on these external testing 
 frameworks is brittle and difficult to get right.
 
 Proposed solution
 
 We propose the re-introduction of the testDependencies parameter in 
 Package Manifests to support external test-only dependencies. To support 
 local test-only targets we also propose the introduction of the 
 testTargets parameter and an extension of the existing swift test command 
 to support individual invocation of these targets.
 
 Detailed design
 
 The behavior of the new testDependencies parameter mirrors that of the 
 existing dependencies parameter with one important difference: fetched 
 dependencies are only built to support package-defined test targets as 
 part of an invocation of swift test.
 
 import PackageDescription
 
 let package = Package(
 name: "Foo",
 targets: [
 Target(name: "Foo")
 ],
 dependencies: [
 .Package(url: "https://github.com/org/ana.git;, versions: 
 Version(1,0,0)...Version(1,9,9)),
 ],
 testDependencies: [
 .Package(url: "https://github.com/org/anism.git;, versions: 
 Version(1,0,0)...Version(1,9,9)),
 ]
 )
>>> 
>>> I think this feature should be called local dependencies (or maybe dev 
>>> dependencies) because it can be used for tests as well as regular targets. 
>>> As an example say you have a networking library package and you want to 
>>> create an example CLI target which uses a JSON mapper package. You 

Re: [swift-evolution] Strings in Swift 4

[Nate Cook via swift-evolution]

> On Jan 30, 2017, at 8:51 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
>> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution 
>> :
>> 
>> Could we add subscript labels to the list of options? While keeping the 
>> range syntax is appealing, I'm concerned it may cause confusion if the 
>> operators are used out of context.
> 
> Good point!
> 
>> The wording is up for debate, but something like this should be a fair 
>> alternative:
>> items[from: i]
>> items[upTo: i]
> 
> For me that's at least as readable as the range syntax.
> 
>> 
>> Sorry if this has been covered elsewhere (can't find the answer in this 
>> thread), but my first questions on discovering these operators (my source of 
>> confusion) would be what happens if I try the following:
>> let partialRange = 0..< //is this an infinite range?
>> let x = items[partialRange] //shouldn't this cause an out of bounds error?
> 
> Good point! Probably this shouldn't be allowed, making the literal range 
> syntax with open ends tied into the subscript which is a bit confusing indeed.

`partialRange` here is an incomplete range, not an infinite one. When you use 
an incomplete range to subscript a collection, the collection "completes" it by 
filling in the start or end index as required. You can see more about the 
details of incomplete ranges in this proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md

One other aspect of incomplete ranges that I haven't seen discussed (though I 
may have missed it) is how they work inpattern matching. It would be nice to 
use incomplete ranges in switch statements, so that instead of:

switch x {
case let y where y < 0: print("< 0")
case 0...10: print("0-10")
case let y where y > 10: print("> 10")
default: print("wat")
}

we could write:

switch x {
case ..<0: print("< 0")
case 0...10: print("0-10")
case 10...: print("> 10")
default: print("wat")
}

To me, that implies that we'll want a postfix ... operator to exist, though I 
agree it's not clear what it should do in a subscript. Are there contexts in 
which we would want i... and i..< to do different things?

Nate

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

Re: [swift-evolution] Public struct init is unexpectedly internal

[Matthew Johnson via swift-evolution]

> On Jan 30, 2017, at 3:32 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 1:30 AM, David Sweeris > > wrote:
>> 
>> 
>>> On Jan 30, 2017, at 1:21 AM, Slava Pestov >> > wrote:
>>> 
 
 On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution 
 > wrote:
 
 So I’ve got this code in a package called “SomeLib":
 public struct SomeType {
 public var text = "SomeText"
 }
 and then, in another package, write this:
 import SomeLib
 print(SomeType().text)
 and then run swift build, I get this error:
 error: 'SomeType' initializer is inaccessible due to 'internal' protection 
 level
 
 "Well that’s odd… there isn’t even an initializer to be internal or 
 public”, I said to myself. Then I proceeded to futz around with it for a 
 while before having a lightbulb moment:
 public struct SomeType {
 public var text = "SomeText"
 public init() {} //this fixes it
 }
 
 
 In cases like this where the struct is public and all its stored 
 properties are both public and already have values, should we make the 
 implicit init() function also be public? Seems like the “least surprising” 
 thing to do.
>>> 
>>> This is intentional. I believe the core team’s rationale is that public 
>>> APIs should always be explicitly written down in source. So your example 
>>> above defining a public init() is correct.
>> 
>> Oh, I knew (well, suspected) it was intentional… I just didn't recall if 
>> we’d discussed this specific scenario before. If we did, then I don’t want 
>> to rehash it.
> 
> I think there was a proposal floating around for ‘flexible member-wise 
> initialization’. This would allow explicitly defining an initializer (to make 
> it public or @_inlineable or whatever) without writing out the boilerplate to 
> initialize all members.
> 
> I don’t have the link offhand, and I don’t remember what the conclusion was, 
> but if you’re interested you might want to look into it and revive it. ;-)

I was the author of this proposal.  It was deferred.  The review brought a lot 
of good ideas to light so it will look somewhat different when it gets revived. 
 I have been assuming it is out of scope for Phase 1 but plan to revive it when 
the time comes.  

If this *is* in scope right now please let me know and I’ll find some time to 
start a new discussion thread outlining two possible directions we could take.

> 
> Slava
> 
>> 
>> - Dave Sweeris
> 
> ___
> 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] Subclass Existentials

[Matthew Johnson via swift-evolution]

> On Jan 29, 2017, at 10:47 PM, Slava Pestov  wrote:
> 
> 
>> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson >> > wrote:
>>> 
 On Jan 29, 2017, at 3:24 PM, Xiaodi Wu > wrote:
 
 On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson > wrote:
 
> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu  > wrote:
> 
> On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson  > wrote:
> 
>> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu > > wrote:
>> 
>> On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > > wrote:
>> 
>>> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson 
>>> > wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 Cool. Another avenue of improvement here is relaxing the single-class 
 spelling rule for the sake of composing typealiases.
 
 As Matthew mentioned, if I have class Base and typealiases Foo = Base 
 & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & 
 Bar.
 
 It'd be nice to go one step further: given class Derived : Base, if I 
 have typealiases Foo2 = Base & Protocol1 and Bar2 = Derived & 
 Protocol2, then it could be permitted to write Foo2 & Bar2, since 
 there is effectively only one subclass requirement (Derived).
 
 As I understand it, the rationale for allowing only one subclass 
 requirement is that Swift supports only single inheritance. Thus, two 
 disparate subclass requirements Base1 & Base2 would make your 
 existential type essentially equivalent to Never. But Base1 & Base1 & 
 Base1 is fine for the type system, the implementation burden (though 
 greater) shouldn't be too awful, and you would measurably improve 
 composition of typealiases.
>>> 
>>> Yes, this is what I was indicating in my post as well.
>>> 
>>> Are you suggesting that Base1 & Base2 compose to a type that is treated 
>>> identically to Never do you think it should be an immediate compiler 
>>> error?  I remember having some discussion about this last year and 
>>> think somebody came up with a very interesting example of where the 
>>> former might be useful.
>>> 
>>> Last year's discussion totally eludes me for some reason. But sure, if 
>>> deferring the error until runtime is actually useful then why not? In 
>>> the absence of an interesting use case, though, I think it'd be nice 
>>> for the compiler to warn you that Base1 & Base2 is not going to be what 
>>> you want.
>> 
>> Deferring to runtime isn’t what I mean.  If you try to actually *do* 
>> anything that requires an instance of `Base1 & Based` (which you almost 
>> always would) you would still get a compile time error.
>> 
>> I managed to dig up the example from last year’s thread and it is 
>> definitely a good one:
>> 
>> func intersection(ts; Set, us: Set) -> Set
>> 
>> The desire is that we are always able to produce a result set.  When T & 
>> U is uninhabitable it will simply be an empty set just like Set 
>> has a single value which is the empty set.
>> 
>> Currently, Set is impossible because Never is not Hashable :)
> 
> Ahh, good point.  I hadn’t tried it.  It can easily be made Hashable with 
> a simple extension though - this code compiles today:
> 
> extension Never: Hashable {
> public var hashValue: Int { return 0 }
> }
> public func ==(lhs: Never, rhs: Never) -> Bool { return false }
> let s = Set()
> 
>> Since concrete types *can't* be used, this example seems like it'd be of 
>> little use currently. How widely useful would it be to have an 
>> intersection facility such as this when T != U even if that restriction 
>> were lifted, though? Seems like the only real useful thing you can do 
>> with generic Set is based on the fact that it'd be 

Re: [swift-evolution] [Discussion] mailing list alternative

[Rudolf Adamkovič via swift-evolution]

+1 for either e-mail or GitHub issues. No need for yet another tool...

R+

> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> I'm surprised there is so little support for JIRA. Anyone think it's a bad 
>> tool for the job?
>> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution 
>> > wrote:
>> I haven't yet seen a good answer to the question: who is going to put in the 
>> long-term commitment to host and maintain a replacement solution, moderate 
>> forums, make technical upgrades and backups, and perform all the other 
>> maintenance and administrative work it takes to properly run a system like 
>> Discourse, a web forum, or even a bug tracker.
>> 
>> I will volunteer to be a moderator of the Swift forums. I have time 
>> available, and the core team surely has better things to do.
>> 
>> Nevin
>> ___
>> 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
> 
> Personally, I’d prefer if we used GitHub Issues. I like keeping the current 
> state of the project together with the known issues in it. It also has better 
> formatting and actually supports some kind of syntax highlighting for Swift 
> code.
> 
> I just assumed that some of our requirements (e.g. syncing with Apple’s 
> internal “radar” system) disqualified it.
> 
> The reason why we don’t have topics every month about migrating our 
> bug-tracking system is that JIRA (while perhaps not optimal) is at least 
> passable. That’s more than you can say for the mailing lists, most of the 
> time.
> 
> - Karl
> ___
> 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] Strings in Swift 4

[Thorsten Seitz via swift-evolution]

> Am 24.01.2017 um 20:28 schrieb Dave Abrahams via swift-evolution 
> :
> 
> 
>> on Sun Jan 22 2017, James Froggatt  wrote:
>> 
>> Could we add subscript labels to the list of options? While keeping
>> the range syntax is appealing, I'm concerned it may cause confusion if
>> the operators are used out of context.
>> 
>> The wording is up for debate, but something like this should be a fair 
>> alternative:
>> items[from: i]
>> items[upTo: i]
> 
> If we were to do that, I'd want to drop range notation altogether and
> just require this for slicing:
> 
>  items[from: i, upTo: j]
> 
> The point here is to create a single unified idiom that can be used
> everywhere.
> 
>> Sorry if this has been covered elsewhere (can't find the answer in
>> this thread), but my first questions on discovering these operators
>> (my source of confusion) would be what happens if I try the following:
>> let partialRange = 0..< //is this an infinite range?
> 
> It is not a Range, but a RangeExpression with no upper bound.
> 
>> let x = items[partialRange] //shouldn't this cause an out of bounds error?
> 
> No, the upper bound is filled in by the collection

Ah, that makes sense! 

-Thorsten 


> 
>>  Begin Message  
>> Group: gmane.comp.lang.swift.evolution 
>> MsgID: <0a458383-2415-4ed4-ad28-88393a671...@nondot.org> 
>> 
 On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution 
 
>>> wrote:
>>> 
 On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
  wrote:
 
 on Fri Jan 20 2017, Joe Groff  wrote:
 
> Jordan points out that the generalized slicing syntax stomps on '...x'
> and 'x...', which would be somewhat obvious candidates for variadic
> splatting if that ever becomes a thing. Now, variadics are a much more
> esoteric feature and slicing is much more important to day-to-day
> programming, so this isn't the end of the world IMO, but it is
> something we'd be giving up.
 
 Good point, Jordan.
>>> 
>>> In my experiments with introducing one-sided operators in Swift 3, I
>>> was not able to find a case where you actually wanted to write
>>> `c[i...]`. Everything I tried needed to use `c[i..<]` instead. My
>>> conclusion was that there was no possible use for postfix `...`;
>>> after all, `c[i...]` means `c[i...c.endIndex]`, which means
>>> `c[i..>> on `index(after:)`.
>> 
>> Right, the only sensible semantics for a one sided range with an open
>> end point is that it goes to the end of the collection.  I see a few
>> different potential colors to paint this bikeshed with, all of which
>> would have the semantics “c[i..> 
>> 1) Provide "c[i...]":
>> 2) Provide "c[i..<]":
>> 3) Provide both "c[i..<]” and "c[i…]":
>> 
>> Since all of these operations would have the same behavior, it comes down to 
>> subjective questions:
>> 
>> a) Do we want redundancy?  IMO, no, which is why #3 is not very desirable.
>> b) Which is easier to explain to people?  As you say, "i..< is shorthand for 
>> i..> and simple, which leans towards #2.
>> c) Which is subjectively nicer looking?  IMO, #1 is much nicer
>> typographically.  The ..< formulation looks like symbol soup,
>> particularly because most folks would not put a space before ].
>> 
>> There is no obvious winner, but to me, I tend to prefer #1.  What do other 
>> folks think?
>> 
>>> If that's the case, you can reserve postfix `...` for future variadics 
>>> features, while using
>> prefix `...` for these one-sided ranges.
>> 
>> I’m personally not very worried about this, the feature doesn’t
>> exist yet and there are lots of ways to spell it.  This is something
>> that could and probably should deserve a more explicit/heavy syntax
>> for clarity.
>> 
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> )ß
>> 
>> - End Message - 
>> 
>> From James
>> ___
>> 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] Strings in Swift 4

[Olivier Tardieu via swift-evolution]

Thanks for the clarifications.
More comments below.

dabrah...@apple.com wrote on 01/24/2017 05:50:59 PM:

> Maybe it wasn't clear from the document, but the intention is that
> String would be able to use any model of Unicode as a backing store, and
> that you could easily build unsafe models of Unicode... but also that
> you could use your unsafe model of Unicode directly, in string-ish ways.

I see. If I understand correctly, it will be possible for instance to 
implement an unsafe model of Unicode with a UInt8 code unit and a 
maxLengthOfEncodedScalar equal to 1 by only keeping the 8 lowest bits of 
Unicode scalars.



> > A lot of machine processing of strings continues to deal with 8-bit 
> > quantities (even 7-bit quantities, not UTF-8).
> > Swift strings are not very good at that. I see progress in the 
manifesto 
> > but nothing to really close the performance gap with C.
> > That's where "unsafe" mechanisms could come into play.
> 
> extendedASCII is supposed to address that.  Given a smart enough
> optimizer, it should be possible to become competitive with C even
> without using unsafe constructs.  However, we recognize the importance
> of being able to squeeze out that last bit of performance by dropping
> down to unsafe storage.

I doubt a 32-bit encoding can bridge the performance gap with C in 
particular because wire protocols will continue to favor compact 
encodings. Incoming strings will have to be expanded to the extendedASCII 
representation before processing and probably compacted afterwards. So 
while this may address the needs of computationally intensive string 
processing tasks, this does not help simple parsing tasks on simple 
strings.



> > To guarantee Unicode correctness, a C string must be validated or 
> > transformed to be considered a Swift string.
> 
> Not really.  You can do error-correction on the fly.  However, I think
> pre-validation is often worthwhile because once you know something is
> valid it's much cheaper to decode correctly (especially for UTF-8).

Sure. Eager vs. lazy validation is a valuable distinction, but what I am 
after here is side-stepping validation altogether. I understand now that 
user-defined encodings will make side-stepping validation possible.



> > If I understand the C String interop section correctly, in Swift 4,
> > this should not force a copy, but traversing the string is still
> > required. 
> 
> *What* should not force a copy?

I would like to have a constructor that takes a pointer to a 
null-terminated sequence of bytes (or a sequence of bytes and a length) 
and turns it into a Swift string without allocation of a new backing store 
for the string and without copying the bytes in the sequence from one 
place in memory to another. I understand this may require the programmer 
to handle memory management for the backing store.



> > I hope I am correct about the no-copy thing, and I would also like to
> > permit promoting C strings to Swift strings without validation.  This
> > is obviously unsafe in general, but I know my strings... and I care
> > about performance. ;)
> 
> We intend to support that use-case.  That's part of the reason for the
> ValidUTF8 and ValidUTF16 encodings you see here:
> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/
> core/Unicode2.swift#L598
> and here:
> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/
> core/Unicode2.swift#L862

OK



> > More importantly, it is not possible to mutate bytes in a Swift string
> > at will.  Again it makes sense from the point of view of always
> > correct Unicode sequences.  But it does not for machine processing of
> > C strings with C-like performance.  Today, I can cheat using a
> > "_public" API for this, i.e., myString._core.  _baseAddress!.  This
> > should be doable from an official "unsafe" API.
> 
> We intend to support that use-case.
> 
> > Memory safety is also at play here, as well as ownership.  A proper
> > API could guarantee the backing store is writable for instance, that
> > it is not shared.  A memory-safe but not unicode-safe API could do
> > bounds checks.
> >
> > While low-level C string processing can be done using unsafe memory
> > buffers with performance, the lack of bridging with "real" Swift
> > strings kills the deal.  No literals syntax (or costly coercions),
> > none of the many useful string APIs.
> >
> > To illustrate these points here is a simple experiment: code written
> > to synthesize an http date string from a bunch of integers.  There are
> > four versions of the code going from nice high-level Swift code to
> > low-level C-like code.  (Some of this code is also about avoiding ARC
> > overheads, and string interpolation overheads, hence the four
> > versions.)
> >
> > On my macbook pro (swiftc -O), the performance is as follows:
> >
> > interpolation + func:  2.303032365s
> > interpolation + array: 1.224858418s
> > append:0.918512377s
> > memcpy:0.182104674s

Re: [swift-evolution] Public struct init is unexpectedly internal

[Chris Lattner via swift-evolution]

See: 
https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md

-Chris

> On Jan 30, 2017, at 1:26 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Unfortunately, I've come across this several times, but read here that it's 
> intended behavior. If I remember correctly, it has something to do with the 
> automatically generated initializers - it's implicitly internal so that you 
> don't expose the initializer by mistake.
> 
> The most annoying about it is, however, when the constructor has several 
> parameters - when you declare 
> 
>   public var text: String
> 
> Swift automatically generates an initializor that takes a text parameter, but 
> it is internal. When you have 4-5 members, the initializer gets quite long.
> 
> And if you want to have it public, you need to declare it and then assign 
> each member, which is tedious. I'd prefer some kind of an annotation on the 
> struct, for example:
> 
> @init(public)
> public struct SomeType { ... }
> 
>> On Jan 30, 2017, at 10:12 AM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> So I’ve got this code in a package called “SomeLib":
>> public struct SomeType {
>> public var text = "SomeText"
>> }
>> and then, in another package, write this:
>> import SomeLib
>> print(SomeType().text)
>> and then run swift build, I get this error:
>> error: 'SomeType' initializer is inaccessible due to 'internal' protection 
>> level
>> 
>> "Well that’s odd… there isn’t even an initializer to be internal or public”, 
>> I said to myself. Then I proceeded to futz around with it for a while before 
>> having a lightbulb moment:
>> public struct SomeType {
>> public var text = "SomeText"
>> public init() {} //this fixes it
>> }
>> 
>> 
>> In cases like this where the struct is public and all its stored properties 
>> are both public and already have values, should we make the implicit init() 
>> function also be public? Seems like the “least surprising” thing to do.
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The lack of namespaces is leading people astray

[Adrian Zubarev via swift-evolution]

If I remember correctly it has been said that we don't need namespaces in favor 
of submodules, which schould solve these issues.

-- 
Adrian Zubarev
Sent with Airmail 

Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

> 
> The lack of namespaces is making people create all kinds of "design patterns".
> 
> struct API { 
> static let endpoint = "http://example.com/api;
> }
> 
> Here is an "improvement" to the above "design pattern" to prevent 
> instantiating API: 
> 
> struct API { 
> private init() {}
> static let endpoint = "http://example.com/api;
> }
> 
> Finally, here is another "improvement" that uses enum instead of struct to 
> avoid having to write the private initializer: 
> 
> enum API { 
> static let endpoint = "http://example.com/api;
> }
> 
> I doubt any of you find this beautiful. Yet these "design patterns" (just 
> hacks IMO) are spreading like the plague because of the lack of namespaces. 
> 
> What do you think? 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] The lack of namespaces is leading people astray

[Tuur Anton via swift-evolution]

The lack of namespaces is making people create all kinds of "design patterns".

struct API {    static let endpoint = "http://example.com/api"}
Here is an "improvement" to the above "design pattern" to prevent instantiating 
API:
struct API {    private init() {}    static let endpoint = 
"http://example.com/api"}
Finally, here is another "improvement" that uses enum instead of struct to 
avoid having to write the private initializer:
enum API {    static let endpoint = "http://example.com/api"}
I doubt any of you find this beautiful. Yet these "design patterns" (just hacks 
IMO) are spreading like the plague because of the lack of namespaces.
What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

[Tino Heth via swift-evolution]

> 2. More on Arrays
> 
> Before, I’ve proposed expressions like “4 * Int” for arrays. But, looking 
> back, it’s not very Swift-y. I had problems with some forms of the syntax 
> giving the specification indices in the reverse order of the dereferencing 
> indices. It looks too quick-and-dirty. And I want to have a revolution over 
> arrays from C, like we gave the enum type.
> 
> The new inspiration came from me looking at a random blog about Swift (1?) 
> tuples, where a 2-Int tuple can be expressed by “(Int, Int)” and a 12-Int 
> tuple by “(Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int)”, I 
> thought the latter was too excessive, and that there should be a way to 
> reduce the repetition. Oh:
> 
>   (repeat Int for 12)

I remember that discussion and I was happy that despite an enthusiastic start, 
it went nowhere:
Imho translating fixed-size arrays to tuples is just a hack that should be 
fixed, not extended.

Arrays are one of the most basic concepts in programming, so I don't want to 
mix them with tuples - especially as there is a clean alternative (there are 
still some pieces missing, but "Vector" looks much better 
than any tuple-magic to me).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Public struct init is unexpectedly internal

[Charlie Monroe via swift-evolution]

Unfortunately, I've come across this several times, but read here that it's 
intended behavior. If I remember correctly, it has something to do with the 
automatically generated initializers - it's implicitly internal so that you 
don't expose the initializer by mistake.

The most annoying about it is, however, when the constructor has several 
parameters - when you declare 

public var text: String

Swift automatically generates an initializor that takes a text parameter, but 
it is internal. When you have 4-5 members, the initializer gets quite long.

And if you want to have it public, you need to declare it and then assign each 
member, which is tedious. I'd prefer some kind of an annotation on the struct, 
for example:

@init(public)
public struct SomeType { ... }

> On Jan 30, 2017, at 10:12 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> So I’ve got this code in a package called “SomeLib":
> public struct SomeType {
> public var text = "SomeText"
> }
> and then, in another package, write this:
> import SomeLib
> print(SomeType().text)
> and then run swift build, I get this error:
> error: 'SomeType' initializer is inaccessible due to 'internal' protection 
> level
> 
> "Well that’s odd… there isn’t even an initializer to be internal or public”, 
> I said to myself. Then I proceeded to futz around with it for a while before 
> having a lightbulb moment:
> public struct SomeType {
> public var text = "SomeText"
> public init() {} //this fixes it
> }
> 
> 
> In cases like this where the struct is public and all its stored properties 
> are both public and already have values, should we make the implicit init() 
> function also be public? Seems like the “least surprising” thing to do.
> 
> - Dave Sweeris
> ___
> 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] Public struct init is unexpectedly internal

[Slava Pestov via swift-evolution]

> On Jan 30, 2017, at 1:30 AM, David Sweeris  wrote:
> 
> 
>> On Jan 30, 2017, at 1:21 AM, Slava Pestov > > wrote:
>> 
>>> 
>>> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution 
>>> > wrote:
>>> 
>>> So I’ve got this code in a package called “SomeLib":
>>> public struct SomeType {
>>> public var text = "SomeText"
>>> }
>>> and then, in another package, write this:
>>> import SomeLib
>>> print(SomeType().text)
>>> and then run swift build, I get this error:
>>> error: 'SomeType' initializer is inaccessible due to 'internal' protection 
>>> level
>>> 
>>> "Well that’s odd… there isn’t even an initializer to be internal or 
>>> public”, I said to myself. Then I proceeded to futz around with it for a 
>>> while before having a lightbulb moment:
>>> public struct SomeType {
>>> public var text = "SomeText"
>>> public init() {} //this fixes it
>>> }
>>> 
>>> 
>>> In cases like this where the struct is public and all its stored properties 
>>> are both public and already have values, should we make the implicit init() 
>>> function also be public? Seems like the “least surprising” thing to do.
>> 
>> This is intentional. I believe the core team’s rationale is that public APIs 
>> should always be explicitly written down in source. So your example above 
>> defining a public init() is correct.
> 
> Oh, I knew (well, suspected) it was intentional… I just didn't recall if we’d 
> discussed this specific scenario before. If we did, then I don’t want to 
> rehash it.

I think there was a proposal floating around for ‘flexible member-wise 
initialization’. This would allow explicitly defining an initializer (to make 
it public or @_inlineable or whatever) without writing out the boilerplate to 
initialize all members.

I don’t have the link offhand, and I don’t remember what the conclusion was, 
but if you’re interested you might want to look into it and revive it. ;-)

Slava

> 
> - Dave Sweeris

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

Re: [swift-evolution] Public struct init is unexpectedly internal

[David Sweeris via swift-evolution]

> On Jan 30, 2017, at 1:21 AM, Slava Pestov  wrote:
> 
>> 
>> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution 
>> > wrote:
>> 
>> So I’ve got this code in a package called “SomeLib":
>> public struct SomeType {
>> public var text = "SomeText"
>> }
>> and then, in another package, write this:
>> import SomeLib
>> print(SomeType().text)
>> and then run swift build, I get this error:
>> error: 'SomeType' initializer is inaccessible due to 'internal' protection 
>> level
>> 
>> "Well that’s odd… there isn’t even an initializer to be internal or public”, 
>> I said to myself. Then I proceeded to futz around with it for a while before 
>> having a lightbulb moment:
>> public struct SomeType {
>> public var text = "SomeText"
>> public init() {} //this fixes it
>> }
>> 
>> 
>> In cases like this where the struct is public and all its stored properties 
>> are both public and already have values, should we make the implicit init() 
>> function also be public? Seems like the “least surprising” thing to do.
> 
> This is intentional. I believe the core team’s rationale is that public APIs 
> should always be explicitly written down in source. So your example above 
> defining a public init() is correct.

Oh, I knew (well, suspected) it was intentional… I just didn't recall if we’d 
discussed this specific scenario before. If we did, then I don’t want to rehash 
it.

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

Re: [swift-evolution] Public struct init is unexpectedly internal

[Slava Pestov via swift-evolution]

> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> So I’ve got this code in a package called “SomeLib":
> public struct SomeType {
> public var text = "SomeText"
> }
> and then, in another package, write this:
> import SomeLib
> print(SomeType().text)
> and then run swift build, I get this error:
> error: 'SomeType' initializer is inaccessible due to 'internal' protection 
> level
> 
> "Well that’s odd… there isn’t even an initializer to be internal or public”, 
> I said to myself. Then I proceeded to futz around with it for a while before 
> having a lightbulb moment:
> public struct SomeType {
> public var text = "SomeText"
> public init() {} //this fixes it
> }
> 
> 
> In cases like this where the struct is public and all its stored properties 
> are both public and already have values, should we make the implicit init() 
> function also be public? Seems like the “least surprising” thing to do.

This is intentional. I believe the core team’s rationale is that public APIs 
should always be explicitly written down in source. So your example above 
defining a public init() is correct.

Slava

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

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

[swift-evolution] Public struct init is unexpectedly internal

[David Sweeris via swift-evolution]

So I’ve got this code in a package called “SomeLib":
public struct SomeType {
public var text = "SomeText"
}
and then, in another package, write this:
import SomeLib
print(SomeType().text)
and then run swift build, I get this error:
error: 'SomeType' initializer is inaccessible due to 'internal' protection level

"Well that’s odd… there isn’t even an initializer to be internal or public”, I 
said to myself. Then I proceeded to futz around with it for a while before 
having a lightbulb moment:
public struct SomeType {
public var text = "SomeText"
public init() {} //this fixes it
}


In cases like this where the struct is public and all its stored properties are 
both public and already have values, should we make the implicit init() 
function also be public? Seems like the “least surprising” thing to do.

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

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

[Alexey Komnin via swift-evolution]

Hello to everyone.

Let me put my two cents.

>> I didn’t want the SortedArray to conform to MutableCollection or
>> even RandomAccessCollection as I felt it was not needed just to
>> support binary search and prevent re-sorting.
>
> You are right not to support MutableCollection or
> RangeReplaceableCollection, as those would allow you to violate the
> “sorted” invariant.  However, it should conform to
> RandomAccessCollection; that's really easy to implement and would
> improve ease-of-use a lot.

Are we able to add some kind of type constraint which allows
append/prepend operations on a particular collection? Seems like a
good replacement for MutableCollection in this case. It should be
available to append elements greater or equal to the last element in
SortedArray, isn't it?

Regards,
Alex Komnin.



On Mon, Jan 30, 2017 at 3:21 AM, Dave Abrahams via swift-evolution
 wrote:
>
> Hi Cihat,
>
> Thanks for diving in here!  For reference, here's the last thing I said
> about this topic (IIRC):
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016729.html
>
> Also
> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift.gyb#L679
>
> Note: the comment there isn't quite right: 
> 
>
> on Sun Jan 29 2017, Cihat Gündüz  wrote:
>
>> Hi guys, I know this topic is probably out of scope for Swift 4
>> and a proposal was already rejected for Swift 3, but I’d like to share
>> my two cents on this as I just wrote a SortedArray class with support
>> for binary search in my open source library HandySwift.
>>
>> You can see my classes current implementation here:
>> https://github.com/Flinesoft/HandySwift/blob/cd7ae7041c8174cd655f24eae653f76697875a48/Sources/Structs/SortedArray.swift
>>
>> My goal was to provide only what is commonly needed when working with
>> big arrays in algorithms. For me this included:
>>
>> - having a type that keeps a sorted array to prevent re-sorting (solution: 
>> the SortedArray class)
>
> Sounds consistent with my feedback... but it doesn't conform to
> RandomAccessCollection.  Why not?
>
>> - have a method that can find an object using binary search (solution: the 
>> index method)
>
> Please see the algorithms prototype
>
>> - allow partitioning the array into smaller parts (solution: subscript, 
>> prefix & suffix methods)
>
> * The collection returned by the slicing subscript should obey the law
>
>  a[i..
>   Normally that means you want to make it a different type from a.
>
>> - prevent re-implementing the Array class (solution: a getter to the
>>   stored internal array)
>
> Not sure I understand what this is supposed to mean.
>
>> Also note that the SortedArray in my approach allows all types that
>> conform to `Sequence` as input with `Comparable` elements and saves
>> them into a sorted array on initialization. That array is also
>> publicly read-accessible. Inserting and deleting objects from the
>> SortedArray are possible, too, but that’s just few of the
>> MutableCollection methods.
>
> Actually no, those are RangeReplaceableCollection methods.
>
>> I didn’t want the SortedArray to conform to MutableCollection or
>> even RandomAccessCollection as I felt it was not needed just to
>> support binary search and prevent re-sorting.
>
> You are right not to support MutableCollection or
> RangeReplaceableCollection, as those would allow you to violate the
> “sorted” invariant.  However, it should conform to
> RandomAccessCollection; that's really easy to implement and would
> improve ease-of-use a lot.
>
>
>> Maybe my approach can somehow help forming the final solution to be
>> included into Swift once this features is tackled again.
>>
>> Best regards,
>> Cihat
>> ___
>> 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] protocol-oriented integers (take 2)

[Brent Royal-Gordon via swift-evolution]

> On Jan 29, 2017, at 10:07 PM, Dave Abrahams  wrote:
> 
 It might make a great deal of sense to support bitwise operations on
 this type, 
>>> 
>>> I think that's a model of SetAlgebra, then, isn't it?
>> 
>> Hmm, arguably. It's a shame that we won't be able to use it with
>> things like `OptionSet`, though.
> 
> Why not?  That conforms to SetAlgebra.

I mean that `OptionSet.RawValue` currently has to conform to 
`BitwiseOperations`, but would now need to conform to `BinaryInteger` (or a 
sub-protocol).

-- 
Brent Royal-Gordon
Architechies

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