[swift-evolution] Problems with generics - should be fixed for Xcode 9?

Greetings Old chestnut, sort of partially solved but still problems. Now we can nest types in generic types, what I want is : class Event { class Args { public static let empty = Args() // error : Static stored properties not supported in generic types } } But the static let is not

Re: [swift-evolution] Subscripts assignable to closure vars

Hi Jordan > Le 15 sept. 2017 à 23:55, Jordan Rose a écrit : > > The crash is already fixed in master, thanks to Alex Hoppen's work on making > actual subscripts distinct from the name "subscript". > > I think John's right that this should not be allowed. After all, a

[swift-evolution] Subscripts assignable to closure vars

Just came across this. I want to be able to hold onto the reference to a subscript "method" for later use. Assigning the subscript to a var in the init of a type raises a segmentation fault. Should this - could this - be allowed? protocol DataProvider { associatedtype ItemType

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

Pardon me for jumping in without a whole load of quoting of previous messages but : 1. My mailbox is getting crammed with messages that are over 90% quote, sometimes running to hundreds of lines 2. I can't find a convenient message to attach this reply to Matthew, please don't take any of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> It's part of what has become Swift style and I'm quite happy about it. Indent > on case and on case content is too much indenting :) > >> On 3 Mar 2017, at 11:06, Karl Wagner via swift-evolution >> wrote: >> >> >>> On 3 Mar 2017, at 05:52, T.J. Usiyan via

Re: [swift-evolution] [Draft] Fix Private Access Levels

> For example, I had to split this class into multiple files using extensions: > https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift > I had to remove 'private'

Re: [swift-evolution] Analysis of existing scopes

> Le 25 févr. 2017 à 02:55, Xiaodi Wu a écrit : > > It is a useful generalization of an absolutely obligatory feature for new > `private`. Consider the following: > > ``` > private class Foo { > private class Bar { > /* blank */ class Baz { } > } > } > ``` > >

Re: [swift-evolution] Analysis of existing scopes

> Le 23 févr. 2017 à 20:48, Matthew Johnson a écrit : > > Sometimes APIs are used internally in production while eventually planned for > public visibility. New features in Apple’s frameworks often start life this > way. Hmmm. In my experience, if I wanted to

Re: [swift-evolution] Analysis of existing scopes

> Le 23 févr. 2017 à 14:59, Matthew Johnson a écrit : > > The rationale for this is that it allows you to explore the eventual design > of a type without exposing it. When you are confident in the design all you > need to does modify the access modifier of the type

Re: [swift-evolution] Analysis of existing scopes

And now I find, what I consider to be, a very peculiar anomaly in method visibility. private class PrivateBaseClass { internal func internalFunc() { } public func publicFunc() { } open func openFunc() { } } private class PrivateDerivedClass : PrivateBaseClass { fileprivate

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 22 févr. 2017 à 01:19, David Waite a écrit : > >> Is there not a value in forking this discussion into which keywords are >> truly about visibility control and which are about extensibility control? > > Possibly; they are two axes. However, I’m hoping that

Re: [swift-evolution] Analysis of existing scopes

> Le 22 févr. 2017 à 17:53, BJ Homer a écrit : > > My understanding is that “private” when written at file scope is exactly > equivalent to “fileprivate”. That is, at the top level it’s tied to the file, > not to the type’s scope. This means that the default access level

Re: [swift-evolution] [Draft] Fix Private Access Levels

> From my point of view the "underlying issues with access" is that we have no > well-designed scoped access modifiers in addition to module/file access > levels. I do think they are two axis of the access control/documentation, and > should work together to aim the better code quality and

Re: [swift-evolution] Analysis of existing scopes

> Le 22 févr. 2017 à 16:31, Joanna Carter a > écrit : > > After much to-ing and fro-ing about scopes on Swift… Now to classes : Classes declared as private are actually just as visible as if they were declared to be fileprivate. private class PrivateClass {

[swift-evolution] Analysis of existing scopes

After much to-ing and fro-ing about scopes on Swift, I, for one, am getting confused about exactly what effects the present scopes have on the various fundamental types used in Swift (protocols, classes, structs, enums, ordinal types) Therefore, if you will indulge me, I would like to start a

Re: [swift-evolution] 'Public' class visibility specifiers

> Le 21 févr. 2017 à 12:02, Brent Royal-Gordon <br...@architechies.com> a écrit > : > >> On Feb 20, 2017, at 8:47 AM, Joanna Carter via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> When it comes to visibilities on classes, why,

Re: [swift-evolution] 'Public' class visibility specifiers

> Le 21 févr. 2017 à 10:28, Slava Pestov a écrit : > > There is one important difference, but it is rather obscure. ‘final’ allows a > class to conform to protocols where ’Self’ appears in invariant position in > requirements. For example, say you have the following: > > …

Re: [swift-evolution] 'Public' class visibility specifiers

> Le 20 févr. 2017 à 19:18, Dimitri Racordon a > écrit : > > Sorry I pressed the wrong button, and the mail was sent right away. > I was about to add that I could give it a try, or offer my help. Since I still haven't worked out how to submit a proposal, if you know

Re: [swift-evolution] final + lazy + fileprivate modifiers

Joanna Carter Carter Consulting Envoyé de mon iPad > Le 20 févr. 2017 à 18:40, Vladimir.S a écrit : > >> On 20.02.2017 20:04, Joanna Carter wrote: >> I'm not sure why ; with 'extensible' available to code within the same >> file, why would you still need fileprivate anywy?

Re: [swift-evolution] 'Public' class visibility specifiers

> Le 20 févr. 2017 à 18:21, Dimitri Racordon a > écrit : > > I’d agree with the proposition of eliminating open. > It does look as an additional layer of complexity for a use case that is imho > not so common. Do you think it's worth a formal proposal? -- Joanna

Re: [swift-evolution] 'Public' class visibility specifiers

> Le 20 févr. 2017 à 18:07, Vladimir.S a écrit : > > With 'public' we can't have subtypes outside of the module, but can have > subtypes inside the module. With 'final' you can't have subtype even inside > module. > That was the main idea, that your module knows all the

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 20 févr. 2017 à 15:30, Dimitri Racordon a > écrit : > > I think that fileprivate is fine, and that the drawback of having very large > files is acceptable, Having had to debug code for my clients in past years, I can say that, from real world experience,

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

> Perhaps 'type' access is 'set' level unless explicitly exposed: > private(get: file, set: scope, type: module) In a word - Yikes! Why on earth do access modifiers have to be sooo complicated? I have written absolutely massive frameworks in C# with nothing but : public - Access is not

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 20 févr. 2017 à 13:29, David Hart a écrit : > > I don't agree with this point. I'm for a file-based private, but I definitely > do NOT want access control eliminated, quite the contrary. I think the > arguments are much subtle than what is presented here. I want strong

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Let's be clear here: Are you thinking of this exclusively as a feature for > override points, or are you asking for a `protected` feature in general? What I am trying to get across is that the concept of fileprivate, as it stands, is almost a waste of effort, in that it only allows privileged

Re: [swift-evolution] final + lazy + fileprivate modifiers

> It's not that it's not meant to be called, but to be called from certain > context. Coming back to a codebase after a while, you don't need to remember > that method is not meant to be called out of certain context and if you name > your methods well, you don't really need to go and take a

Re: [swift-evolution] final + lazy + fileprivate modifiers

> While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary complications that > only serve to clutter the language. > > It would make a lot more sense to just have

Re: [swift-evolution] final + lazy + fileprivate modifiers

> No, sorry, I don't agree with you. > Current situation forces us to generate huge source files or write each > type in its own submodule/file. IMO it is very naturally to have a need to > protect access to some details *even* in the same file(please find David > Sweeris's answer in previous

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> This definition of `scoped` is actually much different than the current > `private` which restricts visibility to the *current* scope. Your definition > allows visibility in an unlimited number of scopes that just happen to be of > the same type. I don’t think `scoped` is a good name for

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> > Here's an idea in three points: > > 1. Return to the Swift 2 definition of `private`. > 2. Introduce `scoped` to limit the visibility to within the same type, > subtype, or extension. > 3. Allow mixing the two. > > So you have: > > private // current file > private

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Was surprised that you expressed exactly what I'm thinking about this subject. > > I do believe even in Swift we need a way to say "only code that *knows* what > it does should see this" and to not force us to write(and manage) the the > code in same file. > Yes, some implementation details

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> The beauty of Swift 2's access modifiers was that they were based around > files and modules, explicitly rejecting types and scopes as units for > determining visibility. It seems at base there's a group of people who reject > that decision altogether. Hence, new `private`, proposals around

Re: [swift-evolution] Simplifying Access Using 'Hidden'

What still strikes me as odd is that we now seem to have a plethora of visibilities, some of which do not provide for a given context, some of which seem to be looking for a context to justify their existence. Whatever it is called, I find the idea of a file scope visibility somewhat bizarre

Re: [swift-evolution] Simplifying Access Using 'Hidden'

Le 13/02/2017 à 15:15, Adrian Zubarev via swift-evolution a écrit : > –1 > > I won’t even try to be constructive on this one. It simply makes me > tired of all this access modifier mess. |open|, |closed|, |public|, > |internal|, now |hidden|, |fileprivate|, |directoryprivate|, >

[swift-evolution] Swiftier implementation of Measurement and Unit

I have spent some time working on a version of the Measurement and Unit held in the apple/swift-corelibs-foundation section of GitHub. How can I best find out if my efforts are worthwhile? Joanna ___ swift-evolution mailing list

Re: [swift-evolution] [Discussion] "with" statement/method

As much as I detested the 'with' construct in Delphi, with all its accompanying opportunities for errors of scope, if you really think it a good idea, then you need to consider the possibility of those who want to 'with' more than one target. In which case, the use of $0, $1, etc would seem

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

Hi Doug > In programming-language circles, this feature is called “dependent types” > (see, e.g., https://en.wikipedia.org/wiki/Dependent_type), and it introduces > significant complicates into a type system. For example, determining whether > two types are equivalent becomes a run-time

[swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

I often find myself needing to construct an instance of a bound generic type at runtime, in much the same manner as I would a "standard" type. e.g. As for a standard type… let aType = Int.Type let anInt = aType.init(0) I also want to be able to use the same mechanism for a generic type…

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

> It’s inconvenient that structs can’t inherit, and so things like Int and > Double aren’t known as numbers. Should there be a Number protocol that > encompasses all things number-like? Taje a look at the IntegerType and FloatingPointType -- Joanna Carter Carter Consulting (de mon iPhone)

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I’ve seen a number of concerns on this list about moduleprivate, and how it > penalizes folks who want to explicitly write their access control. I’ve come > to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

If I may be so bold, as a programmer with over 25 years of experience, in multiple languages… Although I can see the reasoning behind "redefining" visibility scope for Swift, I find myself both agreeing and disagreeing with various aspects. Apart from Delphi, I've never come across a use of

Re: [swift-evolution] Binding generic types using a metatype parameter

>> extension PropertyType >> { >> private static func create() -> Property >> { >>typealias SelfType = Self >> >>return Property.init() >> } >> } > > Oops, that's definitely a bug. Excellent! I would also say that I have had a different error with… private static func create() ->

Re: [swift-evolution] Binding generic types using a metatype parameter

Of course, after all this effort, I still have the problem of how to get the Any.Type from the SubjectType property of a Mirror into a PropertyType.Type. What would really make life easier here would be the ability to extend Any. Any chance? Joanna -- Joanna Carter Carter Consulting

Re: [swift-evolution] Binding generic types using a metatype parameter

I want to thank you for your "rubber duck" consultancy; I now have a working factory mechanism… protocol PropertyFactory { } extension PropertyFactory { static func createProperty() -> PropertyProtocol { typealias ValueType = Self return Property() } } extension Int :

Re: [swift-evolution] Binding generic types using a metatype parameter

Well, I've been playing some more and come up with an idea that seems to be thwarted by the compiler… protocol PropertyFactory { } extension PropertyFactory { // what I'd like to do but that doesn't compile static func createProperty() -> PropertyProtocol { return Property() }

Re: [swift-evolution] Binding generic types using a metatype parameter

Hi Joe > > You can accomplish this with Swift today by casting your Any.Type to a > Protocol.Type that provides an initializer: > > protocol Deserializable { > init(deserializedFrom stream: DeserializationStream) > } > > func deserializeValue(type type: Any.Type, from stream: >

Re: [swift-evolution] Binding generic types using a metatype parameter

My apologies. I seem to have managed to get this subject as a reply to another. I'm not accustomed to mailing list forums. Could an admin move it if necessary? Joanna -- Joanna Carter Carter Consulting ___ swift-evolution mailing list