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

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

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

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

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

> 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

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

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:

Re: [swift-evolution] Initializers

> 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

Re: [swift-evolution] Subclass Existentials

> 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,

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

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:

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

> 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

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

> 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

Re: [swift-evolution] extending typealiases

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

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

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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

> 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,

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

> 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

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

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

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

> 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

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

> 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

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

> 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

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

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

Re: [swift-evolution] Strings in Swift 4

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

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

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

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

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

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

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>

Re: [swift-evolution] Strings in Swift 4

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

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

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

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

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 >

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

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 {

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

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

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

> 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

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

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

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

> 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

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

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?

Re: [swift-evolution] Initializers

> 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

Re: [swift-evolution] Subclass Existentials

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

Re: [swift-evolution] Strings in Swift 4

> 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 =

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

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

Re: [swift-evolution] Initializers

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

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

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 }

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

• 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

Re: [swift-evolution] Initializers

> 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

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

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

Re: [swift-evolution] Annotation of Warnings/Errors

> 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

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

> 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: > > >

Re: [swift-evolution] Initializers

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 >

[swift-evolution] Initializers

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

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

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

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

> 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

Re: [swift-evolution] Strings in Swift 4

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

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

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: > >

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

> 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

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

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

Re: [swift-evolution] Strings in Swift 4

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

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

> 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,

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

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

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

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

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

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,

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

> 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

Re: [swift-evolution] Strings in Swift 4

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

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

~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

Re: [swift-evolution] Strings in Swift 4

> 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

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

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

Re: [swift-evolution] Subclass Existentials

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

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

+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 >>

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

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

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

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

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

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))

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

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 =

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

> 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.

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

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

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

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

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

> 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

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

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

[swift-evolution] Public struct init is unexpectedly internal

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

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

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 >

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

> 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