Re: [swift-evolution] [Proposal] Enums with stored properties

[David Hart via swift-evolution]

Perhaps it is a bit ugly, but I don’t know if allowing stored properties on 
enums is the solution: that looks very ugly to me too.

> On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution 
>  wrote:
> 
> I would love to be able to have stored properties in addition to the varying 
> elements. 
> 
> Now, I end up creating a secondary struct T and doing case a(T, whatever), 
> b(T, whatever), c(T, whatever), etc. where the same associated structure is 
> every case, *or* I end up putting the enum into a struct which means the 
> guiding semantics are the struct and not the enumeration. Both approaches are 
> ugly. 
> 
> -- E
> 
>> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Mateusz,
>> 
>> To me, "Enumeration defines a type with well defined set of possible values" 
>> seems to contradict the idea of having properties that can have different 
>> values. What could you do with this special enum - what would the code that 
>> uses it look like?
>> 
>> 
>> 
>> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and 
>> I think it works quite well.
>> 
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
> 
> ___
> 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] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

Hi Jay,

> To me, "Enumeration defines a type with well defined set of possible values"
> seems to contradict the idea of having properties that can have different
> values.
I think its more about the way you see enumeration type. In most cases
enum cases just carry over some information. When you need to get that
additional
information you will use switch or rawValue. On one hand we currently
do have an enums with associated values, where you can attach
different values with single enum case. On the other hand we do have
enums with rawType where you can already store some information in
enum cases. Having possibility to store properties would just be an
extension to the rawType case.

> What could you do with this special enum - what would the code that
> uses it look like?
I don't see it as special type of enums, its more or less the same
case as accessing rawValue property (please look at my examples in
initial mail). You can think of them as enums that are able carry over
some more information than only a RawType value.

Let me once again share a code from initial proposal email :
enum Format {
case SMALL(30, 30)
case MEDIUM(60, 60)
case LARGE(120, 120)
var width: Double
var height: Double
init(width: Double, height: Double) {
self.width = width
self.height = height
}
}

In that example you have an enum carrying over some extra informations.

regards
--
| Mateusz Malczak


2016-10-10 2:03 GMT+02:00 Jay Abbott :
> Mateusz,
>
> To me, "Enumeration defines a type with well defined set of possible values"
> seems to contradict the idea of having properties that can have different
> values. What could you do with this special enum - what would the code that
> uses it look like?
>
>
>
> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>  wrote:
>>
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
>> and I think it works quite well.
>>
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
>>   private let unFormat : FormatBacking
>>
>>   static var Small : Format {
>> return Format(unFormat: .SMALL(30, 30))
>>   }
>>
>>   static var Medium : Format {
>> return Format(unFormat: .MEDIUM(60, 60))
>>   }
>>
>>   static var Large : Format {
>> return Format(unFormat: .LARGE(120, 120))
>>   }
>>
>>   var width : Int {
>> switch self.unFormat {
>> case let .SMALL(w, _):
>>   return w
>> case let .MEDIUM(w, _):
>>   return w
>> case let .LARGE(w, _):
>>   return w
>> }
>>   }
>>
>>   var height : Int {
>> switch self.unFormat {
>> case let .SMALL(_, h):
>>   return h
>> case let .MEDIUM(_, h):
>>   return h
>> case let .LARGE(_, h):
>>   return h
>> }
>>   }
>> }
>>
>> Yeah, you’re still subject the switching stuff you mentioned before, but I
>> don’t think this is a whole lot of code.  Java’s constants are convenient
>> but they are an oddly structural feature in a particularly nominal language
>> which makes it not scale particularly cleanly.
>>
>> ~Robert Widmann
>>
>> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution
>>  wrote:
>>
>> I agree, you can achieve similar result using structs (as shown in my
>> example 2). But it feels more natural to define it using an
>> enumeration type. Enumeration defines a type with well defined set of
>> possible values. Sometimes where are additional informations liked
>> with enumeration cases (like in example). Using structs for this is
>> more like a walk-around because you are using an open type to mimic a
>> closed set of possible value. What do you think about that?
>>
>> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>>
>> This is precisely what a struct is for, why would you want to be able to
>> do this with enums instead?
>>
>> Hi all,
>> I would like to know you opinion on one feature I feel would be a real
>> 'nice to have' extension to currently available enumeration type. Which is
>> an enumeration type with stored properties. It is sometimes useful to store
>> some extra informations along with enumeration cases. Idea here is to add
>> possibility to define an enumeration type with stored, immutable,
>> properties, defined at compile time for all cases. In opposition to
>> currently available associated values, stored properties should be constant
>> values stored as a part of enumeration case. Proposed feature would be
>> treated as a new feature along the associated values and raw values.
>>
>> Please take a look at an example to illustrate this:
>> ```swift
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>> ```
>>
>> Similar feature is currently available for example in Java
>> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

Hi,
Im currently using similar structure in my projects. But every time I
use this kind of code to carry over some extra information with enum
cases I see it as a walk-around for language limitation. Enumeration
type in swift is already powerful with associated values and
rawValues. If you look at it from that perspective you will see that
having stored properties is an extension to rawType usage.

> Java’s constants are convenient but they are an oddly structural feature in a 
> particularly nominal language
> which makes it not scale particularly cleanly.

why do  you think such a feature would not scale cleanly? can you
elaborate a bit more on that sentence please

--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info


2016-10-09 5:55 GMT+02:00 Robert Widmann :
> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and
> I think it works quite well.
>
> struct Format {
>   enum FormatBacking {
> case SMALL(Int, Int)
> case MEDIUM(Int, Int)
> case LARGE(Int, Int)
>   }
>   private let unFormat : FormatBacking
>
>   static var Small : Format {
> return Format(unFormat: .SMALL(30, 30))
>   }
>
>   static var Medium : Format {
> return Format(unFormat: .MEDIUM(60, 60))
>   }
>
>   static var Large : Format {
> return Format(unFormat: .LARGE(120, 120))
>   }
>
>   var width : Int {
> switch self.unFormat {
> case let .SMALL(w, _):
>   return w
> case let .MEDIUM(w, _):
>   return w
> case let .LARGE(w, _):
>   return w
> }
>   }
>
>   var height : Int {
> switch self.unFormat {
> case let .SMALL(_, h):
>   return h
> case let .MEDIUM(_, h):
>   return h
> case let .LARGE(_, h):
>   return h
> }
>   }
> }
>
> Yeah, you’re still subject the switching stuff you mentioned before, but I
> don’t think this is a whole lot of code.  Java’s constants are convenient
> but they are an oddly structural feature in a particularly nominal language
> which makes it not scale particularly cleanly.
>
> ~Robert Widmann
>
> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution
>  wrote:
>
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
>
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>
> This is precisely what a struct is for, why would you want to be able to do
> this with enums instead?
>
> Hi all,
> I would like to know you opinion on one feature I feel would be a real 'nice
> to have' extension to currently available enumeration type. Which is an
> enumeration type with stored properties. It is sometimes useful to store
> some extra informations along with enumeration cases. Idea here is to add
> possibility to define an enumeration type with stored, immutable,
> properties, defined at compile time for all cases. In opposition to
> currently available associated values, stored properties should be constant
> values stored as a part of enumeration case. Proposed feature would be
> treated as a new feature along the associated values and raw values.
>
> Please take a look at an example to illustrate this:
> ```swift
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> ```
>
> Similar feature is currently available for example in Java
> (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>
> Currently there are at least tree ways to solve this limitation.
>
> 1. use enumeration type with custom struct as a rawValue cons:
> a lot of additional code to define structs and implement
> `ExpressibleByStringLiteral`
> not really possible for more complex types, where a complex string parser
> would be required
>
> example:
> ```swift
> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> public init(stringLiteral value: String) {
> let set = CharacterSet(charactersIn: "x")
> let values = value.components(separatedBy: set)
> if let width = Int(values[0]), let height = Int(values[1]) {
> self.init(width: width, height: height)
> } else {
> self.init(width: 0, height: 0)
> }
> }
> init(extendedGraphemeClusterLiteral value: String){
> self.init(stringLiteral: value)
> }
> init(unicodeScalarLiteral value: String) {
> self.init(stringLiteral: value)
> }
> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
> return (lhs.width == rhs.widt

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

Hi,
> Perhaps it is a bit ugly, but I don’t know if allowing stored properties on
> enums is the solution: that looks very ugly to me too.

That may look ugly, but can be very useful, if only you think
rawValue's are useful then you should also agree that stored
properties would be useful :)

--
| Mateusz Malczak


2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
:
> Perhaps it is a bit ugly, but I don’t know if allowing stored properties on
> enums is the solution: that looks very ugly to me too.
>
> On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
>  wrote:
>
> I would love to be able to have stored properties in addition to the varying
> elements.
>
> Now, I end up creating a secondary struct T and doing case a(T, whatever),
> b(T, whatever), c(T, whatever), etc. where the same associated structure is
> every case, *or* I end up putting the enum into a struct which means the
> guiding semantics are the struct and not the enumeration. Both approaches
> are ugly.
>
> -- E
>
> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>  wrote:
>
> Mateusz,
>
> To me, "Enumeration defines a type with well defined set of possible values"
> seems to contradict the idea of having properties that can have different
> values. What could you do with this special enum - what would the code that
> uses it look like?
>
>
>
> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>  wrote:
>>
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
>> and I think it works quite well.
>>
>> struct Format {
>>   enum FormatBacking {
>> case SMALL(Int, Int)
>> case MEDIUM(Int, Int)
>> case LARGE(Int, Int)
>>   }
>
>
> ___
> 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] private & fileprivate

[Alex Blewitt via swift-evolution]

> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On 8 Oct 2016, at 16:47, Braeden Profile > > wrote:
>> 
>>> 
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I was thinking that the domains themselves could be associated with a 
>>> domain, so you could create alternate domains which are also 
>>> publicly-visible, but distinct from the default, “public” domain.
>>> 
>>> For example, if you have a bunch of methods which should be visible to 
>>> subclasses, but you don’t want them to clutter your regular interface. 
>>> Perhaps they have names which are confusingly-similar to the public API. I 
>>> believe that is what “protected” is typically used for.
>> 
>> Yes, but “protected" was specifically put down by the core team, seeing that 
>> any code from outside the library should see the class as one well-designed 
>> whole, not something with complicated, visible implementation details.  If 
>> your class-internal methods are confusing (and aren’t necessary for normal 
>> use), they shouldn’t be made public in any way.  Subclasses would too easily 
>> confuse the distinction between your implementation methods and your public 
>> ones.
>> 
>> For what it’s worth, I was only confused by “private” and “fileprivate” for 
>> a minute or two until I looked up the actual proposal.  I haven’t had 
>> trouble with it, and it does actually provide more flexibility for code 
>> access at the file level than we had before.  Even if the syntax is clunky.
> 
> I’m not saying that (file)private is confusing - it’s very clear about what 
> it does. But it is limiting; anything that wants access to those semi-private 
> details needs to live in the same file. That’s clearly not scalable. Enormous 
> files many thousands of lines long are easy for the compiler to digest, but 
> less easy for humans to understand and navigate. In fact, I believe this 
> whole “file-based” access control originally came out of the compiler’s 
> implementation details.
> 
> I'm interested in more information about this. What sorts of code have you 
> been writing where a file would have to be thousands of lines long in order 
> to accommodate `fileprivate`? Many entire modules are only thousands of lines 
> long--is there a reason this code couldn't be refactored into a module of its 
> own? As mentioned by Matthew, isn't this calling for some notion of 
> submodules?

I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up scope 
for internal implementation details. The implementation that I've got on my 
GitHub account is currently at 885 lines; but I'm still working on other parts 
and my currently checked out version has 1125 lines of code, in a single file.

https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift
 


Submodules aren't the right answer here, because Foundation as a while is a 
module that won't be split apart. And for performance reasons, you want the 
internal functions (defined fileprivate) to be considered as eligible for 
optimisation by the compiler in the absence of (say) whole module optimisation.

Right now, the only way to do that is to have the fiileprivate implementations 
in the same file as the rest of the implementation.

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I understand Charlie. A few points though:
a) I'm talking about pure Swift, this is absolutely nothing to do with
Objective-C;
b) If you read back on the AO thread you'll see that initially I was
thinking "I want AO because it will give me stored properties in
extensions" when really I should have been thinking "I want stored
properties in extensions". So this discussion is no longer about AO at all,
hence the new subject.
c) Protocol conformance in an extension cannot tell the compiler to add
members to classes defined in other precompiled modules, as it is not
compiling them. When you do have the code and you are compiling it
yourself, you actually don't *need* stored properties in extensions because
you can work around it (although it would be nice), so the case where you
actually need it is where you want to extend someone else's precompiled
class.

On Mon, 10 Oct 2016 at 06:04 Charlie Monroe 
wrote:

> No, I've also suggested how it would be implemented. It would, as I've
> described, require support from the compiler and runtime - the protocol
> conformance would tell the compiler to include an extra space in the
> instance layout for [AnyHashable : Any], which would get to be used by the
> runtime to store AO.
>
> Note that the implementation noted below does not use any locks at all -
> unlike ObjC AO, it's not thread-safe.
>
> With AO, the main bottleneck always was that everything was stored in one
> place - this way, each object would have its own AOs stored within itself.
> This way, instead of a single spin (!) lock (
> https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm),
> you can use a lock pool - e.g. you have a dozen locks, depending on the
> hash of the object itself, you decide which lock to use - this lowers the
> contention a lot.
>
> Try to run a few threads, read, write AO using the ObjC runtime - you'll
> see how painfully slow it is - this is not something that should be in
> Swift.
>
>
> On Oct 9, 2016, at 10:15 PM, Jay Abbott  wrote:
>
> Charlie,
>
> What you suggest defines how you would use it from your code, not how it
> would be implemented in the language. If you look at my AO implementation
> it does what you say:
>
> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
> i.e. has a protocol called 'Associable' and you opt classes into it to get
> the behaviour. This works and is usable, but the implementation leaves a
> lot to be desired (it's not optimal and while the interface is clean the
> implementation is not). Anyway - I was trying to steer the conversation
> AWAY from AOs towards stored properties in extensions, since Robert Widmann
> helped me to understand that AO was just a *means*, whereas stored
> properties in extensions is the *end*.
>
> In fact we don't need a solution to the problem of "how to define/use
> stored properties in extensions" because the existing syntax for extensions
> is perfectly fine. Currently you get an error if you try to define a stored
> property in an extension, so no new syntax is needed, we just remove that
> error and make it work.
>
> Of course a runtime-check may be needed if there is doubt about whether a
> dynamically linked module supported this feature - so this might invalidate
> what I just said above, or it might still be possible if the runtime does
> the check automatically when an extension is linked and puts a different
> implementation in place for older modules.
>
> I'm just airing some thoughts at the moment to see what people think and
> try to get some technical feedback on viability. So it's not all fully
> thought through :D
>
>
> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe 
> wrote:
>
> There is a 4th way.
>
> Introduce an internal protocol Associatable, which would tell the compiler
> to add an additional (hidden) field to the object which would include the
> "dictionary" of key -> value associated values. (It would be off-limits to
> extensions, of course).
>
> This way:
>
> - it won't be a single dictionary containing all the associated values
> - classes can opt-in to this
> - the dictionary will be per-instance
>
> This is a midway between the current implementation of ObjC associated
> objects and of what someone has suggested to have an extra space for each
> object for the AO...
>
>
> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have been thinking further on this and in addition to my previous two
> thoughts about implementation, I have had another idea...
>
> 3. If there is a bit spare in the object header somewhere (that is
> currently always zero), this could be used to signify the presence of an
> additional struct that immediately follows after the existing object data.
> I *think* that this method would allow binary compatibility with older
> modules. Instances that have this bit set would allow stored properties in
> extensions. The struct at the end would have one me

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

> On Oct 10, 2016, at 1:13 PM, Jay Abbott  wrote:
> 
> I understand Charlie. A few points though:
> a) I'm talking about pure Swift, this is absolutely nothing to do with 
> Objective-C;

Sure, but in either case you will need to somehow solve locking of the 
structure holding the additional values.

> b) If you read back on the AO thread you'll see that initially I was thinking 
> "I want AO because it will give me stored properties in extensions" when 
> really I should have been thinking "I want stored properties in extensions". 
> So this discussion is no longer about AO at all, hence the new subject.

Agreed, though the actual backing of the values won't be a lot different from 
the AO - it can be called differently, but the fact that it is likely to be 
stored in a dictionary brings resemblence to AO - and what I've mentioned are a 
few downsides to how AO are implemented at this point.

> c) Protocol conformance in an extension cannot tell the compiler to add 
> members to classes defined in other precompiled modules, as it is not 
> compiling them. When you do have the code and you are compiling it yourself, 
> you actually don't *need* stored properties in extensions because you can 
> work around it (although it would be nice), so the case where you actually 
> need it is where you want to extend someone else's precompiled class.

This is why I mentioned that this "magic protocol" would be off limits to 
extensions. Perhaps the choice of a protocol to this was incorrect - better way 
would be to use an annotation like @allows_extension_properties or similar.

I bet you that in any case, there will be a lot of people on this list that 
will want explicit opt-in, or at least a way to opt-out.

> 
> On Mon, 10 Oct 2016 at 06:04 Charlie Monroe  > wrote:
> No, I've also suggested how it would be implemented. It would, as I've 
> described, require support from the compiler and runtime - the protocol 
> conformance would tell the compiler to include an extra space in the instance 
> layout for [AnyHashable : Any], which would get to be used by the runtime to 
> store AO.
> 
> Note that the implementation noted below does not use any locks at all - 
> unlike ObjC AO, it's not thread-safe.
> 
> With AO, the main bottleneck always was that everything was stored in one 
> place - this way, each object would have its own AOs stored within itself. 
> This way, instead of a single spin (!) lock 
> (https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm
>  
> ),
>  you can use a lock pool - e.g. you have a dozen locks, depending on the hash 
> of the object itself, you decide which lock to use - this lowers the 
> contention a lot.
> 
> Try to run a few threads, read, write AO using the ObjC runtime - you'll see 
> how painfully slow it is - this is not something that should be in Swift.
> 
> 
>> On Oct 9, 2016, at 10:15 PM, Jay Abbott > > wrote:
>> 
>> Charlie,
>> 
>> What you suggest defines how you would use it from your code, not how it 
>> would be implemented in the language. If you look at my AO implementation it 
>> does what you say:
>> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
>>  
>> 
>> i.e. has a protocol called 'Associable' and you opt classes into it to get 
>> the behaviour. This works and is usable, but the implementation leaves a lot 
>> to be desired (it's not optimal and while the interface is clean the 
>> implementation is not). Anyway - I was trying to steer the conversation AWAY 
>> from AOs towards stored properties in extensions, since Robert Widmann 
>> helped me to understand that AO was just a *means*, whereas stored 
>> properties in extensions is the *end*.
>> 
>> In fact we don't need a solution to the problem of "how to define/use stored 
>> properties in extensions" because the existing syntax for extensions is 
>> perfectly fine. Currently you get an error if you try to define a stored 
>> property in an extension, so no new syntax is needed, we just remove that 
>> error and make it work.
>> 
>> Of course a runtime-check may be needed if there is doubt about whether a 
>> dynamically linked module supported this feature - so this might invalidate 
>> what I just said above, or it might still be possible if the runtime does 
>> the check automatically when an extension is linked and puts a different 
>> implementation in place for older modules.
>> 
>> I'm just airing some thoughts at the moment to see what people think and try 
>> to get some technical feedback on viability. So it's not all fully thought 
>> through :D
>> 
>> 
>> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe > > wrote:
>> There is a 4th way.
>> 
>> Introduce an in

Re: [swift-evolution] [Proposal] Enums with stored properties

[Jay Abbott via swift-evolution]

Thanks for the explanation Mateusz, I think I understand. So the enum still
only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
properties?

So some code to use it might be:
var aFormat = Format.LARGE
aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change

Is that right?

On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> on
> > enums is the solution: that looks very ugly to me too.
>
> That may look ugly, but can be very useful, if only you think
> rawValue's are useful then you should also agree that stored
> properties would be useful :)
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> :
> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> on
> > enums is the solution: that looks very ugly to me too.
> >
> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> >  wrote:
> >
> > I would love to be able to have stored properties in addition to the
> varying
> > elements.
> >
> > Now, I end up creating a secondary struct T and doing case a(T,
> whatever),
> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> is
> > every case, *or* I end up putting the enum into a struct which means the
> > guiding semantics are the struct and not the enumeration. Both approaches
> > are ugly.
> >
> > -- E
> >
> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >  wrote:
> >
> > Mateusz,
> >
> > To me, "Enumeration defines a type with well defined set of possible
> values"
> > seems to contradict the idea of having properties that can have different
> > values. What could you do with this special enum - what would the code
> that
> > uses it look like?
> >
> >
> >
> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >  wrote:
> >>
> >> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
> >> and I think it works quite well.
> >>
> >> struct Format {
> >>   enum FormatBacking {
> >> case SMALL(Int, Int)
> >> case MEDIUM(Int, Int)
> >> case LARGE(Int, Int)
> >>   }
> >
> >
> > ___
> > 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] private & fileprivate

[Xiaodi Wu via swift-evolution]

I don't find this example persuasive, because:

1125 LOC is on the long side for a single file, but not by any means
"thousands" of LOC.

In any case, having hacked on corelibs-foundation myself, my sense is that
its files are organized in such a way that NSDecimal would be expected to
be implemented in a single file regardless of length.

If Swift had submodules, there's no reason to say that Foundation wouldn't
make use of them to organize its types.

Even if you wished to share implementation details between, say, a
hypothetically split up NSDecimal and Decimal, fileprivate members of
NSDecimal could simply be internal instead, as is done elsewhere in
corelibs-foundation. Note by comparison that, for implementation reasons,
stdlib doesn't use fileprivate scope and all implementation details are
internal or even public and underscored. A compelling argument for more
fine-grained controls here would demonstrate how internal scope in stdlib
or corelibs-foundation actually led to a bug that could have been
prevented--I don't think any such bug exists.
On Mon, Oct 10, 2016 at 04:30 Alex Blewitt  wrote:

>
> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up
> scope for internal implementation details. The implementation that I've got
> on my GitHub account is currently at 885 lines; but I'm still working on
> other parts and my currently checked out version has 1125 lines of code, in
> a single file.
>
>
> https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift
>
> Submodules aren't the right answer here, because Foundation as a while is
> a module that won't be split apart. And for performance reasons, you want
> the internal functions (defined fileprivate) to be considered as eligible
> for optimisation by the compiler in the absence of (say) whole module
> optimisation.
>
> Right now, the only way to do that is to have the fiileprivate
> implementations in the same file as the rest of the implementation.
>
> Alex
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

I think, I have used quite unfortunate naming, which is a root of an
misunderstanding here. By saying 'enums with stored properties' what I
was really thinking about, was enumeration type with stored constant,
immutable properties (constants). I don't want to duplicate 'struct'
type here, but instead I would like to make it possible to store a
const values in enumeration cases. So going back to my example once
again:

Lest define an enumeration type `Format` with 3 possible cases. Each
case will be able to carry over some additional information - in this
case a pair of numbers (but in fact Any? should be possible)

enum Format {
case SMALL(30, 30)
case MEDIUM(60, 60)
case LARGE(120, 120)
var width: Double
var height: Double
init(width: Double, height: Double) {
self.width = width
self.height = height
}
}

I'm not sure about 'var' clause in that example as it causes all the confusion.

I can access additional info stored in enum case, but it cannot be
modified. Format.SMALL doesn't change, as well as non of its
properties.

// allowed usage
let format = Format.SMALL
let width = format.width // this would be equal to 30 (const value
assigned to 'width' property on enum case .SMALL)

// not allowed usage
let format = Format.SMALL
format.width = 40 // error, stored values are immutable and can not be modified

We get all advantages of enumeration type, and, assuming all cases are
describing the same possible state, we can store some extra
information in each case. This can be called a third enumeration type
feature, right next to associated values and rawType.

--
| Mateusz Malczak


2016-10-10 13:40 GMT+02:00 Jay Abbott :
> Thanks for the explanation Mateusz, I think I understand. So the enum still
> only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
> properties?
>
> So some code to use it might be:
> var aFormat = Format.LARGE
> aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change
>
> Is that right?
>
> On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>  wrote:
>>
>> Hi,
>> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
>> > on
>> > enums is the solution: that looks very ugly to me too.
>>
>> That may look ugly, but can be very useful, if only you think
>> rawValue's are useful then you should also agree that stored
>> properties would be useful :)
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> :
>> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
>> > on
>> > enums is the solution: that looks very ugly to me too.
>> >
>> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
>> >  wrote:
>> >
>> > I would love to be able to have stored properties in addition to the
>> > varying
>> > elements.
>> >
>> > Now, I end up creating a secondary struct T and doing case a(T,
>> > whatever),
>> > b(T, whatever), c(T, whatever), etc. where the same associated structure
>> > is
>> > every case, *or* I end up putting the enum into a struct which means the
>> > guiding semantics are the struct and not the enumeration. Both
>> > approaches
>> > are ugly.
>> >
>> > -- E
>> >
>> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >  wrote:
>> >
>> > Mateusz,
>> >
>> > To me, "Enumeration defines a type with well defined set of possible
>> > values"
>> > seems to contradict the idea of having properties that can have
>> > different
>> > values. What could you do with this special enum - what would the code
>> > that
>> > uses it look like?
>> >
>> >
>> >
>> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>> >  wrote:
>> >>
>> >> I’ve started doing this to try and mimic “Smart Constructors” in
>> >> Haskell
>> >> and I think it works quite well.
>> >>
>> >> struct Format {
>> >>   enum FormatBacking {
>> >> case SMALL(Int, Int)
>> >> case MEDIUM(Int, Int)
>> >> case LARGE(Int, Int)
>> >>   }
>> >
>> >
>> > ___
>> > 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] [Proposal] Enums with stored properties

[Jay Abbott via swift-evolution]

Is this what you're trying to achieve, only using a nicer syntax to
represent it?
http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831


On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak  wrote:

> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
>
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
>
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
>
> I'm not sure about 'var' clause in that example as it causes all the
> confusion.
>
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
>
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
>
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be
> modified
>
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
> > Thanks for the explanation Mateusz, I think I understand. So the enum
> still
> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
> > properties?
> >
> > So some code to use it might be:
> > var aFormat = Format.LARGE
> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't
> change
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> >  wrote:
> >>
> >> Hi,
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
> properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >>
> >> That may look ugly, but can be very useful, if only you think
> >> rawValue's are useful then you should also agree that stored
> >> properties would be useful :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> :
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
> properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >> >
> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> >> >  wrote:
> >> >
> >> > I would love to be able to have stored properties in addition to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated
> structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means
> the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> >  wrote:
> >> >
> >> > Mateusz,
> >> >
> >> > To me, "Enumeration defines a type with well defined set of possible
> >> > values"
> >> > seems to contradict the idea of having properties that can have
> >> > different
> >> > values. What could you do with this special enum - what would the code
> >> > that
> >> > uses it look like?
> >> >
> >> >
> >> >
> >> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >> >  wrote:
> >> >>
> >> >> I’ve started doing this to try and mimic “Smart Constructors” in
> >> >> Haskell
> >> >> and I think it works quite well.
> >> >>
> >> >> struct Format {
> >> >>   enum FormatBacking {
> >> >> case SMALL(Int, Int)
> >> >> case MEDIUM(Int, Int)
> >> >> case LARGE(Int, Int)
> >> >>   }
> >> >
> >> >
> >> > ___
> >> > 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
> >

Re: [swift-evolution] [Proposal] Enums with stored properties

[Rien via swift-evolution]

Maybe I am missing something, but is this what you want?

class Size {
   let width: Double
   let height: Double
   init(width: Double, height: Double) { … }
}

enum Format {
case SMALL
case MEDIUM
case LARGE
var size: Size {
 switch self {
   case SMALL: return Size(width: 100, height: 100)
   case MEDIUM: …
   ….
 }
}
}

let format = Format.SMALL
let width = format.size.width

format.size.width = 50 // error, immutable



> On 10 Oct 2016, at 14:35, Jay Abbott via swift-evolution 
>  wrote:
> 
> Is this what you're trying to achieve, only using a nicer syntax to represent 
> it?
> http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831
> 
> 
> On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak  wrote:
> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
> 
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
> 
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> 
> I'm not sure about 'var' clause in that example as it causes all the 
> confusion.
> 
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
> 
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
> 
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be 
> modified
> 
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
> 
> --
> | Mateusz Malczak
> 
> 
> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
> > Thanks for the explanation Mateusz, I think I understand. So the enum still
> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
> > properties?
> >
> > So some code to use it might be:
> > var aFormat = Format.LARGE
> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> >  wrote:
> >>
> >> Hi,
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >>
> >> That may look ugly, but can be very useful, if only you think
> >> rawValue's are useful then you should also agree that stored
> >> properties would be useful :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> :
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >> >
> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> >> >  wrote:
> >> >
> >> > I would love to be able to have stored properties in addition to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> >  wrote:
> >> >
> >> > Mateusz,
> >> >
> >> > To me, "Enumeration defines a type with well defined set of possible
> >> > values"
> >> > seems to contradict the idea of having properties that can have
> >> > different
> >> > values. What could you do with this special enum - what would the code
> >> > that
> >> > uses it look like?
> >> >
> >> >
> >> >
> >> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> >> >  wrote:
> >> >>
> >> >> I’ve started doing this to try and mimic “Smart Constructors” in
> >> >> Haskell
> >> >> and I think it works quite well.
> >> >>
> >> >> struct Format {
> >> >>   enum FormatBacking {
> >> >> case SMALL(In

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

> Is this what you're trying to achieve, only using a nicer syntax to
> represent it?
> http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831

Yes
This similar to example shown in my original email, where struct is
used as a rawType and custom string literal parsing to assign values
to enum cases.
http://swiftlang.ng.bluemix.net/#/repl/57fb8e3e4f9bcf25fdd415cd

What I would like to achieve is (more or less)
http://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8

regards
--
| Mateusz Malczak


2016-10-10 14:35 GMT+02:00 Jay Abbott :
> Is this what you're trying to achieve, only using a nicer syntax to
> represent it?
> http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831
>
>
> On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak  wrote:
>>
>> I think, I have used quite unfortunate naming, which is a root of an
>> misunderstanding here. By saying 'enums with stored properties' what I
>> was really thinking about, was enumeration type with stored constant,
>> immutable properties (constants). I don't want to duplicate 'struct'
>> type here, but instead I would like to make it possible to store a
>> const values in enumeration cases. So going back to my example once
>> again:
>>
>> Lest define an enumeration type `Format` with 3 possible cases. Each
>> case will be able to carry over some additional information - in this
>> case a pair of numbers (but in fact Any? should be possible)
>>
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>>
>> I'm not sure about 'var' clause in that example as it causes all the
>> confusion.
>>
>> I can access additional info stored in enum case, but it cannot be
>> modified. Format.SMALL doesn't change, as well as non of its
>> properties.
>>
>> // allowed usage
>> let format = Format.SMALL
>> let width = format.width // this would be equal to 30 (const value
>> assigned to 'width' property on enum case .SMALL)
>>
>> // not allowed usage
>> let format = Format.SMALL
>> format.width = 40 // error, stored values are immutable and can not be
>> modified
>>
>> We get all advantages of enumeration type, and, assuming all cases are
>> describing the same possible state, we can store some extra
>> information in each case. This can be called a third enumeration type
>> feature, right next to associated values and rawType.
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
>> > Thanks for the explanation Mateusz, I think I understand. So the enum
>> > still
>> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has
>> > some
>> > properties?
>> >
>> > So some code to use it might be:
>> > var aFormat = Format.LARGE
>> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't
>> > change
>> >
>> > Is that right?
>> >
>> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>> >  wrote:
>> >>
>> >> Hi,
>> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
>> >> > properties
>> >> > on
>> >> > enums is the solution: that looks very ugly to me too.
>> >>
>> >> That may look ugly, but can be very useful, if only you think
>> >> rawValue's are useful then you should also agree that stored
>> >> properties would be useful :)
>> >>
>> >> --
>> >> | Mateusz Malczak
>> >>
>> >>
>> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> >> :
>> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
>> >> > properties
>> >> > on
>> >> > enums is the solution: that looks very ugly to me too.
>> >> >
>> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > I would love to be able to have stored properties in addition to the
>> >> > varying
>> >> > elements.
>> >> >
>> >> > Now, I end up creating a secondary struct T and doing case a(T,
>> >> > whatever),
>> >> > b(T, whatever), c(T, whatever), etc. where the same associated
>> >> > structure
>> >> > is
>> >> > every case, *or* I end up putting the enum into a struct which means
>> >> > the
>> >> > guiding semantics are the struct and not the enumeration. Both
>> >> > approaches
>> >> > are ugly.
>> >> >
>> >> > -- E
>> >> >
>> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > Mateusz,
>> >> >
>> >> > To me, "Enumeration defines a type with well defined set of possible
>> >> > values"
>> >> > seems to contradict the idea of having properties that can have
>> >> > different
>> >> > values. What could you do with this special enum - what would the
>> >> > code
>> >> > that
>> >> > uses it look like?
>> >> >
>> >> >
>> >> >
>> >> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
>> >> >  wrote:
>> >> >>
>> >> >> I’ve started doing this to try and mimic “Smart Constructors” in
>> >> >> Haskell
>> >> >> and I think i

Re: [swift-evolution] [Proposal] Enums with stored properties

[Haravikk via swift-evolution]

> On 10 Oct 2016, at 13:04, Mateusz Malczak via swift-evolution 
>  wrote:
> 
> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
> 
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
> 
> enum Format {
>case SMALL(30, 30)
>case MEDIUM(60, 60)
>case LARGE(120, 120)
>var width: Double
>var height: Double
>init(width: Double, height: Double) {
>self.width = width
>self.height = height
>}
> }
> 
> I'm not sure about 'var' clause in that example as it causes all the 
> confusion.
> 
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
> 
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
> 
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be 
> modified
> 
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
> 
> --
> | Mateusz Malczak

Can't this problem most easily be solved by a raw value? Like so:

enum Format : Int {
case small = 30
case medium = 60
case large = 120

var width:Int { return self.rawValue }
var height:Int { return self.rawValue }
}

Granted this becomes more complex if you want to specify widths and heights 
that do not match, as you can't currently specify a tuple as the raw value, but 
if you could then that seems like it would be a better solution to this problem 
surely?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

> Can't this problem most easily be solved by a raw value? Like so:
>
> enum Format : Int {
> case small = 30
> case medium = 60
> case large = 120
>
> var width:Int { return self.rawValue }
> var height:Int { return self.rawValue }
> }

This only solves a problem when width/height are the same. Im talking
here about more general use case when you can assign different values
of different types to an enum case. Please refer to the example code:
https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8

--
| Mateusz Malczak


2016-10-10 15:31 GMT+02:00 Haravikk :
>
> On 10 Oct 2016, at 13:04, Mateusz Malczak via swift-evolution
>  wrote:
>
> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
>
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
>
> enum Format {
>case SMALL(30, 30)
>case MEDIUM(60, 60)
>case LARGE(120, 120)
>var width: Double
>var height: Double
>init(width: Double, height: Double) {
>self.width = width
>self.height = height
>}
> }
>
> I'm not sure about 'var' clause in that example as it causes all the
> confusion.
>
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
>
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
>
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be
> modified
>
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
>
> --
> | Mateusz Malczak
>
>
> Can't this problem most easily be solved by a raw value? Like so:
>
> enum Format : Int {
> case small = 30
> case medium = 60
> case large = 120
>
> var width:Int { return self.rawValue }
> var height:Int { return self.rawValue }
> }
>
>
> Granted this becomes more complex if you want to specify widths and heights
> that do not match, as you can't currently specify a tuple as the raw value,
> but if you could then that seems like it would be a better solution to this
> problem surely?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

> Maybe I am missing something, but is this what you want?

It a good illustration of what I would like to be able to define with
my proposed feature.
But instead to creating a class/struct to in switch case I would like
enumeration type to be able to carry that information within its cases
For example : https://swiftlang.ng.bluemix.net/#/repl/57fb99c54f9bcf25fdd415f3

> class Size {
>let width: Double
>let height: Double
>init(width: Double, height: Double) { … }
> }
>
> enum Format {
> case SMALL
> case MEDIUM
> case LARGE
> var size: Size {
>  switch self {
>case SMALL: return Size(width: 100, height: 100)
>case MEDIUM: …
>….
>  }
> }
> }
>
> let format = Format.SMALL
> let width = format.size.width
>
> format.size.width = 50 // error, immutable
>
>
>
>> On 10 Oct 2016, at 14:35, Jay Abbott via swift-evolution 
>>  wrote:
>>
>> Is this what you're trying to achieve, only using a nicer syntax to 
>> represent it?
>> http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831
>>
>>
>> On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak  wrote:
>> I think, I have used quite unfortunate naming, which is a root of an
>> misunderstanding here. By saying 'enums with stored properties' what I
>> was really thinking about, was enumeration type with stored constant,
>> immutable properties (constants). I don't want to duplicate 'struct'
>> type here, but instead I would like to make it possible to store a
>> const values in enumeration cases. So going back to my example once
>> again:
>>
>> Lest define an enumeration type `Format` with 3 possible cases. Each
>> case will be able to carry over some additional information - in this
>> case a pair of numbers (but in fact Any? should be possible)
>>
>> enum Format {
>> case SMALL(30, 30)
>> case MEDIUM(60, 60)
>> case LARGE(120, 120)
>> var width: Double
>> var height: Double
>> init(width: Double, height: Double) {
>> self.width = width
>> self.height = height
>> }
>> }
>>
>> I'm not sure about 'var' clause in that example as it causes all the 
>> confusion.
>>
>> I can access additional info stored in enum case, but it cannot be
>> modified. Format.SMALL doesn't change, as well as non of its
>> properties.
>>
>> // allowed usage
>> let format = Format.SMALL
>> let width = format.width // this would be equal to 30 (const value
>> assigned to 'width' property on enum case .SMALL)
>>
>> // not allowed usage
>> let format = Format.SMALL
>> format.width = 40 // error, stored values are immutable and can not be 
>> modified
>>
>> We get all advantages of enumeration type, and, assuming all cases are
>> describing the same possible state, we can store some extra
>> information in each case. This can be called a third enumeration type
>> feature, right next to associated values and rawType.
>>
>> --
>> | Mateusz Malczak
>>
>>
>> 2016-10-10 13:40 GMT+02:00 Jay Abbott :
>> > Thanks for the explanation Mateusz, I think I understand. So the enum still
>> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
>> > properties?
>> >
>> > So some code to use it might be:
>> > var aFormat = Format.LARGE
>> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change
>> >
>> > Is that right?
>> >
>> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
>> >  wrote:
>> >>
>> >> Hi,
>> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
>> >> > on
>> >> > enums is the solution: that looks very ugly to me too.
>> >>
>> >> That may look ugly, but can be very useful, if only you think
>> >> rawValue's are useful then you should also agree that stored
>> >> properties would be useful :)
>> >>
>> >> --
>> >> | Mateusz Malczak
>> >>
>> >>
>> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
>> >> :
>> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
>> >> > on
>> >> > enums is the solution: that looks very ugly to me too.
>> >> >
>> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > I would love to be able to have stored properties in addition to the
>> >> > varying
>> >> > elements.
>> >> >
>> >> > Now, I end up creating a secondary struct T and doing case a(T,
>> >> > whatever),
>> >> > b(T, whatever), c(T, whatever), etc. where the same associated structure
>> >> > is
>> >> > every case, *or* I end up putting the enum into a struct which means the
>> >> > guiding semantics are the struct and not the enumeration. Both
>> >> > approaches
>> >> > are ugly.
>> >> >
>> >> > -- E
>> >> >
>> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
>> >> >  wrote:
>> >> >
>> >> > Mateusz,
>> >> >
>> >> > To me, "Enumeration defines a type with well defined set of possible
>> >> > values"
>> >> > seems to contradict the idea of having properties that can have

[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Sean Alling via swift-evolution]

Hey guys and girls and everything in between,

I was discussing this on Twitter.

Perhaps the first step to easing this import system is to allow import 
conditional operators:

&&
||

would be the two of most use (mostly ||).  We could perform the Darwin or Glibc 
import based on order of operations. Should the first import library fail than 
try the second, third, etc. elements until one has either been found or none. 
This avoids creating a whole pure swift library, although that may be a longer 
term goal to create a ecosystem of architecture independent libraries for pure 
swift use cross platform.  Import statements for Darwin/Glibc would end up 
looking like this:

```
import Darwin || Glibc
```

I feel this would be well within line with Swift syntax.

- Sean


-
Sean Alling
Nuclear Engineer

> > It looks like there are 2 views being discussed
> > 
> > Import System : just masks the difference in platform specific names
> > Import Libc : a true attempt at a swift specific view of credible c runtime 
> > equivalent
> > 
> > The first one would be easy to do now and would alleviate all the mindless 
> > #if...#endif we have today.
> > 
> > Regards
> > LM
> > (From mobile)
> > 
> > > On Jul 6, 2016, at 1:13 AM, Chris Lattner via 
> > > swift-evolutionwrote:
> > > 
> > > 
> > > > On Jul 5, 2016, at 2:59 PM, Brian Gesiak via 
> > > > swift-evolutionwrote:
> > > > 
> > > > Sorry to resurrect such an old thread! I understand getting this in 
> > > > Swift 3.0 might not be realistic anymore, but this is still something 
> > > > I’d love to see added to Swift. Could someone advise on whether it 
> > > > still makes sense to spend time on this proposal? Or is this part of 
> > > > Swift too solidified to change at this point?
> > > It is definitely beyond Swift 3.0, but I’d love to see this happen at 
> > > some point, we really need someone to drive the (surely to be 
> > > contentious) design process.
> > > 
> > > -Chris
> > > 
> > > 
> > > > How much would Libc include? The standard C library? POSIX?
> > > > 
> > > > Yes, I had originally anticipated this as including module C and module 
> > > > POSIX. I see that module CUUID was recently added as well, but I don’t 
> > > > think that should be included.
> > > > 
> > > > there are differences (minor, but still) between Glibc and Darwin. 
> > > > Those should be either unified (if possible) or re-arranged so that the 
> > > > unified library shares unified functionality and then each separate one 
> > > > can have its own set of caveats.
> > > > 
> > > > I don’t think the unified import C module should do anything besides 
> > > > obviate the need to write the following:
> > > > 
> > > > #if os(Linux) || os(FreeBSD)
> > > > import Glibc
> > > > #else
> > > > import Darwin
> > > > #endif
> > > > If people feel strongly about unifying the overlay, perhaps we should 
> > > > discuss that in future swift-evolution proposals.
> > > > 
> > > > Personally, I like “import C”, but at the end of the day I’m happy to 
> > > > call it whatever as long as it solves the problem.
> > > > 
> > > > I couldn’t have said it better myself!
> > > > 
> > > > /cc Saleem, since he may have Windows opinions.
> > > > 
> > > > - Brian Gesiak
> > > > 
> > > > 
> > > > > On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky > > > > gmail.com>wrote:
> > > > > A huge +1 on the proposal, I even have a code snippet to import the 
> > > > > platform-appropriate C library. I try to write every new Swift 
> > > > > library cross-platform-by-default now and this would definitely 
> > > > > remove some friction. Not to mention it would future-proof many 
> > > > > libraries which won't need to be updated when a new Swift platform is 
> > > > > added.
> > > > > 
> > > > > Personally, I like "import C", but at the end of the day I'm happy to 
> > > > > call it whatever as long as it solves the problem. I agree with Brian 
> > > > > that with Swift scaling up to 4 or so platforms soon-ish, it's 
> > > > > preferable to not put any extra burden on Swift users if there is an 
> > > > > almost-uniform C API which can be used everywhere.
> > > > > 
> > > > > On Wed, Mar 9, 2016 at 2:03 AM Jordan Rose via 
> > > > > swift-evolutionwrote:
> > > > > > One of the reasons we haven't picked this particular name is if the 
> > > > > > C or C++ committees ever adopted modules. Given that they just got 
> > > > > > punted from C++17, though, maybe that shouldn't hold us back.
> > > > > > 
> > > > > > Jordan
> > > > > > 
> > > > > > 
> > > > > > > On Mar 8, 2016, at 11:13, Brian Gesiak via 
> > > > > > > swift-evolutionwrote:
> > > > > > > 
> > > > > > > # Introduction
> > > > > > > 
> > > > > > > Currently, cross-platform Swift programs that rely on symbols 
> > > > > > > defined in libc (`fputs`, `stderr`, etc.) must all write the same 
> > > > > > > five lines of boilerplate code:
> > > > > > > 
> > > > > > > #if os(Linux) || os(FreeBSD)
> > > > > > > import Glibc
> > > > > > > #else
> > > > > > > 

[swift-evolution] Parameter names in closures in Swift 3 are no longer possible

[Andrew Hart via swift-evolution]

I’ve been a little dismayed to see that closures in Swift 3 no longer have
parameter names. As an example, in Swift 2, a function with a completion
block may look like this:

func sendMessage(completion: (success: Bool, recipientID: String?,
senderID: String?) -> Void) {
//Oh no it failed
completion(success: false, recipientID: nil, senderID: nil)
}

Now, in Swift 3, it looks like this:

func sendMessage(completion: @escaping (_ success: String, _ recipientID:
String?, _ senderID: String?) -> Void {
//Oh no it failed
completion(false, nil, nil)
}

So now all parameter names, if you wish to include them, must be preceded
by a _. Removing the _, it forces you to put it back. Or putting the
parameter name twice, it forces you to replace the first occurrence with a
_.

To me, one of the great advantages of Swift over a language like Python or
Ruby is its self-documenting nature. If I’m calling a function, I don’t
need to look elsewhere for a reference to the parameters I’m using. When
reading back over my code, I don’t have to look elsewhere to check whether
I used the correct parameters, and in the correct order. In Swift 2, I can
easily glance at my code to check its correctness, and I can clearly see
I’m responding to the completion block correctly. In Swift 3, I need to
look elsewhere to see what the parameters in “(false, nil, nil)" refers to,
and that negates one of the key advantages that Swift has.

For this kind of closure, I feel like it’s almost required that we be able
to have parameter names. My request is that if we list the parameter names
explicitly, like in the Swift 2 example, then they appear in the closure
call by default.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Automatic generation of initializer including default values

[Guy Miller via swift-evolution]

Hi,

When I am defining a struct I find myself often using a style as shown in the 
following example:

struct Foo {

var greeting: String
var x: Int
var y: Int
var z: Int

init(greeting: String, x: Int = 1, y: Int = 2, z: Int = 3) {
self.greeting = greeting
self.x = x
self.y = y
self.z = z
}
}

This enables one to write code when one doesn’t need to change defaults:

let f = Foo(greeting: “Hello”)

and when one wishes to change one of the defaults:

let f = Foo(greeting: “Hello”, z: 4)

It would be better if one could write the struct in what I understand is the 
preferred style:

struct Foo {
var greeting: String
var x = 1
var y = 2
var z = 3
}

and have the compiler generate the initializer:

init(name: String, x: Int = 1, y: Int = 2, z: Int = 3) {
self.name = name
self.x = x
self.y = y
self.z = z
}

rather than one where all the parameters that have a default value need to be 
specified in the initializer if one wishes to change just one of them.

Regards,
Guy Miller




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

Re: [swift-evolution] Automatic generation of initializer including default values

[Robert Widmann via swift-evolution]

I'm ambivalent here.  I know this is convenient, but I have a stronger interest 
in controlling my APIs, initializers included.  The more the compiler 
synthesizes, the less control I have and the more code I have to write to make 
up for that.  I don't think there's enough here (yet?) to justify synthesis.

tl;dr  Not everybody chains convenience initializers like this.

~Robert Widmann

2016/10/10 8:27、Guy Miller via swift-evolution  
のメッセージ:

> Hi,
> 
> When I am defining a struct I find myself often using a style as shown in the 
> following example:
> 
> struct Foo {
> 
>var greeting: String
>var x: Int
>var y: Int
>var z: Int
> 
>init(greeting: String, x: Int = 1, y: Int = 2, z: Int = 3) {
>self.greeting = greeting
>self.x = x
>self.y = y
>self.z = z
>}
> }
> 
> This enables one to write code when one doesn’t need to change defaults:
> 
> let f = Foo(greeting: “Hello”)
> 
> and when one wishes to change one of the defaults:
> 
> let f = Foo(greeting: “Hello”, z: 4)
> 
> It would be better if one could write the struct in what I understand is the 
> preferred style:
> 
> struct Foo {
>var greeting: String
>var x = 1
>var y = 2
>var z = 3
> }
> 
> and have the compiler generate the initializer:
> 
> init(name: String, x: Int = 1, y: Int = 2, z: Int = 3) {
>self.name = name
>self.x = x
>self.y = y
>self.z = z
> }
> 
> rather than one where all the parameters that have a default value need to be 
> specified in the initializer if one wishes to change just one of them.
> 
> Regards,
> Guy Miller
> 
> 
> 
> 
> ___
> 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] Parameter names in closures in Swift 3 are no longer possible

[Xiaodi Wu via swift-evolution]

As mentioned previously, the core team has laid out a two-step roadmap to
restoring parameter names:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html

On Mon, Oct 10, 2016 at 10:55 Andrew Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve been a little dismayed to see that closures in Swift 3 no longer have
> parameter names. As an example, in Swift 2, a function with a completion
> block may look like this:
>
> func sendMessage(completion: (success: Bool, recipientID: String?,
> senderID: String?) -> Void) {
> //Oh no it failed
> completion(success: false, recipientID: nil, senderID: nil)
> }
>
> Now, in Swift 3, it looks like this:
>
> func sendMessage(completion: @escaping (_ success: String, _ recipientID:
> String?, _ senderID: String?) -> Void {
> //Oh no it failed
> completion(false, nil, nil)
> }
>
> So now all parameter names, if you wish to include them, must be preceded
> by a _. Removing the _, it forces you to put it back. Or putting the
> parameter name twice, it forces you to replace the first occurrence with a
> _.
>
> To me, one of the great advantages of Swift over a language like Python or
> Ruby is its self-documenting nature. If I’m calling a function, I don’t
> need to look elsewhere for a reference to the parameters I’m using. When
> reading back over my code, I don’t have to look elsewhere to check whether
> I used the correct parameters, and in the correct order. In Swift 2, I can
> easily glance at my code to check its correctness, and I can clearly see
> I’m responding to the completion block correctly. In Swift 3, I need to
> look elsewhere to see what the parameters in “(false, nil, nil)" refers to,
> and that negates one of the key advantages that Swift has.
>
> For this kind of closure, I feel like it’s almost required that we be able
> to have parameter names. My request is that if we list the parameter names
> explicitly, like in the Swift 2 example, then they appear in the closure
> call by default.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Douglas Gregor via swift-evolution]

> On Oct 9, 2016, at 9:45 PM, Tony Constantinides via swift-evolution 
>  wrote:
> 
> In Swift 3.0 you can build Android apps in Linux but only console apps as 
> there is no framework to build GUI apps using JNI.
> What I propose is to build an initial limited framework coded in C that calls 
> enough of the Java Android API via JNI to bootstrap the android app and to 
> create widgets and layouts.A default Androidmanifest.xml file and some files 
> needed to be generated to make a valid android app.
>   The Android API java surface is vast, so this framework needs to be build 
> over many releases to be useful. Developing a graphical Android app requires 
> interaction with "Activities" and the package manager and some widgets like 
> Button and some layouts like "RelativeLayout" and "LinearLayout".
>  The result will be the ability to develop GUI Android apps on Linux using 
> Swift 3.0
> Further support for additional APIs will be provided once the basics are 
> solid..
> Who am I: Senior Android mobile developer with more than six years experience 
> on Android.
> Am I able to build Swift 3.0 on Linux: Yes

The swift-evolution process is primarily focused on the Swift language and 
standard library. Large-scale API development, which binding to/creating a GUI 
library entails, is out-of-scope for this process and should occur in a 
different forum.

Cheers,
Doug


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

Re: [swift-evolution] private & fileprivate

[Douglas Gregor via swift-evolution]

> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I third this sentiment. fileprivate is a nice idea and very clearly has its 
>>> uses (which is why the proposal got traction in the first place), but when 
>>> combined with the other access levels, the language feature as a whole 
>>> feels arbitrary. In practical use, files that I felt were nicely 
>>> encapsulated and hiding implementation details are now a scattered mix of 
>>> access levels, adding cognitive load and making the code look unorganized 
>>> for having the gall to use extensions to split up functionality.
>>> 
>>> Sincerely,
>>>   Zachary Waldowski
>>>   z...@waldowski.me 
>> 
>> Beyond the textual change of using a different modifier name, I don’t see 
>> how the encapsulation and organization of code could be affected. Really, 
>> there’s not much point in rehashing prior discussion of SE-0025 unless 
>> there’s a previously unconsidered angle.
> 
> I strongly agree with this sentiment. SE-0025 was very heavily discussed, and 
> while many people were not satisfied with the solution we went with 
> (including me!), it was what the core team and community converged on. I 
> don't expect us to change access control again until and unless we decide to 
> change the model in some way, and even then I think we'll want to go through 
> extra effort to maintain compatibility with Swift 3. As has been mentioned 
> repeatedly, the bar for source-breaking changes is much higher than it was in 
> the first few months of swift-evolution.
> 
> I actually consider it very lucky that most of our changes so far have been 
> fairly non-controversial. Everybody has a different idea of what would make 
> Swift a better language, and all of us well-meaning. But when those ideas 
> conflict, some group is going to end up unhappy. I'm actually very glad that 
> (a) we haven't had too many of these cases, and (b) even when we have, people 
> have been able to accept it and move on to contributing to the next issue.


Strong agreement here as well. This proposal has been litigated numerous times 
already, and the bar for source-breaking changes is much higher now. To 
effectively re-open the discussion would require a proposal that significant 
changes the model with a lot of evidence that such a new model is a drastic 
improvement over what we have now. “Back out SE-0025” is not a viable option 
now.

- Doug

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

Re: [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

[Joe Groff via swift-evolution]

> On Oct 9, 2016, at 1:10 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Normally in guard and if condition lists, you look up a value in a dictionary 
> and conditionally cast:
> 
> if let value = dict[key] as? T, ...
> 
> The "as?" operator passes the Any? type through, and the lhs result is T, not 
> T?.
> 
> * dict[key] returns Any?
> * Any? as T returns T?, not T??
> * the conditional binding binds T? to T
> * PROFIT!
> 
> However, this (somewhat illogical) "sugar" doesn't happen when you 
> conditionally cast T? to U, for example, when a dictionary is [AnyHashable: 
> String]:
> 
> guard let value = dict["Key"] as? NSString
> else { fatalError() }
> 
> (see http://i.imgur.com/SkXkk6o.jpg )
> 
> * dict[key] returns String?
> * String? as T is guaranteed to fail
> 
> In this case, the compiler asserts that a cast from String? to an unrelated 
> type NSString always fails. You can mitigate this by sticking an "Any" cast 
> in the middle:
> 
> guard let value = dict["Key"] as Any as? NSString
> else { fatalError() }
> 
> If that's not "magic", I don't know what is.  (You can also cast the 
> dictionary to [AnyHashable: NSString], etc.)

This is a bug. 'String as NSString' works, and you can cast through Optionals 
'T? as? U', so transitively this also works, despite the misleading warning. 
Please file a bug report if you haven't yet.

-Joe

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Douglas Gregor via swift-evolution]

> On Oct 8, 2016, at 10:01 PM, Jon Shier via swift-evolution 
>  wrote:
> 
> It’s not that nobody cares, it’s that it’s ultimately up to Apple to decided 
> how this is going to go, and nobody there seems to care. Until a decision is 
> made there, nothing will happen. Even under the best case scenario I wouldn’t 
> expect anything to happen soon, as Apple doesn’t move quickly for stuff like 
> this.
> 
> To my eyes, the Discourse-powered Rust forums look great.

You are confusing perceived inaction for “not caring”. Discourse does look 
promising, but it takes some time to evaluate a different technology before we 
commit to migrating 2,000 participants and some 27,000 existing messages. I 
suggest patience, and starting from the assumption that the people involved are 
competent yet busy.

- Doug

> 
> Jon
> 
> 
>> On Oct 8, 2016, at 7:00 AM, Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> It’s one of those issues where everybody agrees we could do better but 
>> nobody cares enough to do anything about it.
>> 
>> In any case I think Discourse seemed to be the only real option because of 
>> mailing-list support. So I suppose they next step would be to submit a 
>> formal proposal to swift-evo on GitHub?
>> 
>> 
>>> On 7 Oct 2016, at 20:44, Adrian Zubarev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> What happened to that talk? Were any decisions made internally? Any news?
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 21. August 2016 um 17:36:53, Michie via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 Incase, the Swift team decided to use a forum.
 
 I would like to suggest Discourse (http://www.discourse.org 
 ).
 It is one of the most reliable open-source made forum and most  
 companies have been using it as their forum/community eg. Dockers,  
 Let's Encrypt, etc...
 
 The Swift Team has a choice to host it on their own or pay  
 discourse.org  to host it for you. Hosting on their 
 own would be more  
 cheaper and gives you more control on how you want it to be set up. We  
 can easily set up a mailing list to all the people watching the  
 discussion and you can add in your own style of Authentication if  
 needed.
 
 Slack will be very expensive because Slack cost almost $7 per active  
 member per month. If you don't pay, it will definitely be limiting.  
 Also, I don't think using chat for this kind of project will be more  
 productive as people need to revisit some discussions.
 
 I can help the Swift Team set up Discourse if they are interested and  
 they can create a subdomain: https://community.swift.org 
  for it.
 
 Let me know.
 
 Michie :)
 
 Quoting Sean Alling via swift-evolution >>> >:
 
 > +1
 >
 > I think this is a great idea! The use of a mailing list is  
 > manageable for a small (2-10) groups but doesn’t scale to the size  
 > and frequency of comments/replies that the Swift Open Source project  
 > has seen thus far. Not to mention, it reeks of 1996.
 >
 > I’m not sure if we should authenticate users via AppleID, because we  
 > want the Swift community to remain cross-platform going forward.
 >
 > A Slack would be a great idea, for banter but may get crazy. We  
 > would want the slack channels to remain subject pure (i.e., no  
 > shenanigans). Email is good in this regard in that a reply is  
 > expensive and therefore on-topic, whereas slack replies are cheap  
 > and therefore easily off topic. Anyone have any idea to combat that?  
 > Code of Conduct?
 >
 > I think in making this decision we should separate the determination  
 > that the mailing lists are posing too great a burden at our scale  
 > from the selection of what we should use in its stead.
 >
 > - Sean
 >
 >
 >> I think this thread should focus on the mailing list vs forum, Slack is
 >> not a forum. It could be nice to have it as an extra if we need it.
 >>
 >> It looks to me that all benefits of a mailing list can be achieved by a
 >> forum system with excellent support to read and reply using emails. But
 >> the opposite is not true, one single simple example: we can't even link
 >> related thread using email (as Tino mentioned on the Gmane thread).
 >>
 >>
 >>
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> 
>>> _

Re: [swift-evolution] [Proposal] Enums with stored properties

[Kenny Leung via swift-evolution]

This is the way Java enumerations work. 

https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

I think it is a good model, and I think Swift enumerations should also work the 
same way.

An enumeration is a finite set of things. It’s really inconvenient to have to 
limit those things to have only a single attribute.

-Kenny


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

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Tony Constantinides via swift-evolution]

Its a nice cop-out, but this framework is an extension of the standard
library of Swift as it will allow Swift developers to target new mobile
platforms. This is the mailing lists for the evolution of Swift which is
what this is. I not sure any of the other Swift mailing lists suits this
goal. I not making Swift language changes(maybe) but adding an additional
library that developers can build against if they are interested in having
their Swift code running on Android.

Note that the Swift project itself has provided documentation and hooks to
provide this capabailit seen here
https://github.com/apple/swift/blob/master/docs/Android.md
The main issue is that swiftcore is missing on Swift for Linux.

  Its only important to understand I going to build this framework with or
without support from Swift.org. However I want other developers to benefit
from my work and I want to give back to the community. I find it extremely
disappointing if Swift core members reject enhancing Swift to target
additional mobile platforms as making Swift cross-platform is a stated goal.





On Mon, Oct 10, 2016 at 9:41 AM, Douglas Gregor  wrote:

>
> > On Oct 9, 2016, at 9:45 PM, Tony Constantinides via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > In Swift 3.0 you can build Android apps in Linux but only console apps
> as there is no framework to build GUI apps using JNI.
> > What I propose is to build an initial limited framework coded in C that
> calls enough of the Java Android API via JNI to bootstrap the android app
> and to create widgets and layouts.A default Androidmanifest.xml file and
> some files needed to be generated to make a valid android app.
> >   The Android API java surface is vast, so this framework needs to be
> build over many releases to be useful. Developing a graphical Android app
> requires interaction with "Activities" and the package manager and some
> widgets like Button and some layouts like "RelativeLayout" and
> "LinearLayout".
> >  The result will be the ability to develop GUI Android apps on Linux
> using Swift 3.0
> > Further support for additional APIs will be provided once the basics are
> solid..
> > Who am I: Senior Android mobile developer with more than six years
> experience on Android.
> > Am I able to build Swift 3.0 on Linux: Yes
>
> The swift-evolution process is primarily focused on the Swift language and
> standard library. Large-scale API development, which binding to/creating a
> GUI library entails, is out-of-scope for this process and should occur in a
> different forum.
>
> Cheers,
> Doug
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Robert Widmann via swift-evolution]

> On Oct 10, 2016, at 2:04 PM, Tony Constantinides via swift-evolution 
>  wrote:
> 
> Its a nice cop-out, but this framework is an extension of the standard 
> library of Swift

Then it requires a proposal as much.  Bear in mind that the Swift Standard 
Library is platform-agnostic.  Adding support for Android necessarily 
contradicts that and will be a hard sell.  Further, I don’t believe stdlib is 
the right target for this kind of library at all and will lead to the same 
lowest-common-denominator style of application as with Java on every other 
platform they support.  

This doesn’t belong anywhere near core libs, but as a 3rd-party project it 
would certainly be welcome to have Android bindings.

> as it will allow Swift developers to target new mobile platforms. This is the 
> mailing lists for the evolution of Swift which is what this is. I not sure 
> any of the other Swift mailing lists suits this goal. I not making Swift 
> language changes(maybe) but adding an additional library that developers can 
> build against if they are interested in having their Swift code running on 
> Android.  
> Note that the Swift project itself has provided documentation and hooks to 
> provide this capabailit seen here
> https://github.com/apple/swift/blob/master/docs/Android.md 
> 
> The main issue is that swiftcore is missing on Swift for Linux.
> 

Unless Android gets support for Objective-C (shudder) I don’t think you need 
SwiftCore for this.

>   Its only important to understand I going to build this framework with or 
> without support from Swift.org. However I want other developers to benefit 
> from my work and I want to give back to the community. I find it extremely 
> disappointing if Swift core members reject enhancing Swift to target 
> additional mobile platforms as making Swift cross-platform is a stated goal.

I think this is a bit of a strawman.  Members of this community have spent a 
lot of time and effort getting Swift to even build on Android.  To say we’d 
“reject” this because it’s out of bounds for inclusion in the libraries you’re 
trying to include it in is ignoring the larger problems inherent in this 
proposal.

~Robert Widmann 

> 
> 
> 
> 
> 
> On Mon, Oct 10, 2016 at 9:41 AM, Douglas Gregor  > wrote:
> 
> > On Oct 9, 2016, at 9:45 PM, Tony Constantinides via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > In Swift 3.0 you can build Android apps in Linux but only console apps as 
> > there is no framework to build GUI apps using JNI.
> > What I propose is to build an initial limited framework coded in C that 
> > calls enough of the Java Android API via JNI to bootstrap the android app 
> > and to create widgets and layouts.A default Androidmanifest.xml file and 
> > some files needed to be generated to make a valid android app.
> >   The Android API java surface is vast, so this framework needs to be build 
> > over many releases to be useful. Developing a graphical Android app 
> > requires interaction with "Activities" and the package manager and some 
> > widgets like Button and some layouts like "RelativeLayout" and 
> > "LinearLayout".
> >  The result will be the ability to develop GUI Android apps on Linux using 
> > Swift 3.0
> > Further support for additional APIs will be provided once the basics are 
> > solid..
> > Who am I: Senior Android mobile developer with more than six years 
> > experience on Android.
> > Am I able to build Swift 3.0 on Linux: Yes
> 
> The swift-evolution process is primarily focused on the Swift language and 
> standard library. Large-scale API development, which binding to/creating a 
> GUI library entails, is out-of-scope for this process and should occur in a 
> different forum.
> 
> Cheers,
> Doug
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Adrian Zubarev via swift-evolution]

It’s disappointing that you seem not to understand what this mailing list is 
for. Building a Framework does not require the evolution process. It’s all up 
to you to open a GitHub repository and just start building.

Sure you can ask for help, but I believe other platforms like stackoverflow or 
even swift-users would be a better place for that.

And I think your statement about rejection is totally wrong. The core team has 
enough work and responsibility to care about.



-- 
Adrian Zubarev
Sent with Airmail

Am 10. Oktober 2016 um 20:06:26, Tony Constantinides via swift-evolution 
(swift-evolution@swift.org) schrieb:

I find it extremely disappointing if Swift core members reject enhancing Swift 
to target additional mobile platforms as making Swift cross-platform is a 
stated goal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Kevin Nattinger via swift-evolution]

I agree wholeheartedly. An enum case should be a compile-time constant.  IMO, 
“enums” with associated values should properly be a separate entity, called 
“union” as that’s essentially what they are. 

> On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution 
>  wrote:
> 
> This is the way Java enumerations work. 
> 
> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
> 
> I think it is a good model, and I think Swift enumerations should also work 
> the same way.
> 
> An enumeration is a finite set of things. It’s really inconvenient to have to 
> limit those things to have only a single attribute.
> 
> -Kenny
> 
> 
> ___
> 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] [Proposal] Enums with stored properties

[Robert Widmann via swift-evolution]

By imposing that kind of separation you leave an entire class of generic and 
structural programming patterns off the table.  An enumeration is not just an 
enumeration of constants, it is an enumeration of data, and data takes far more 
useful forms than just bitfields - similarly when it does have that form it 
fits precisely into the form of an enum with no cases?  Why artificially 
separate the two concepts when they’re clearly one and the same?

~Robert Widmann

> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> I agree wholeheartedly. An enum case should be a compile-time constant.  IMO, 
> “enums” with associated values should properly be a separate entity, called 
> “union” as that’s essentially what they are. 
> 
>> On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> This is the way Java enumerations work. 
>> 
>> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
>> 
>> I think it is a good model, and I think Swift enumerations should also work 
>> the same way.
>> 
>> An enumeration is a finite set of things. It’s really inconvenient to have 
>> to limit those things to have only a single attribute.
>> 
>> -Kenny
>> 
>> 
>> ___
>> 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] [Proposal] Enums with stored properties

[Adrian Zubarev via swift-evolution]

I haven’t followed the whole topic, but I myself always wished for stored 
properties on Swift enums.

I’d like to throw an idea in the room.

How about to a two type enums? By that I mean something like this:

enum Enum : RawType, StoreType {
case a = (rawInstance1, storeInstance1)
case b = (rawInstance2, storeInstance2)
case c = rawInstance3, storeInstance3 // or not tuple like?
}

let instance = Enum.a
instance.rawValue // would be rawInstance1
instance.value // would be storeInstance1
StoreType could be anything (even another two type enum).

It would be interesting to read what you thing of that simple model. Plus 
should .value be mutable? Maybe we could communicate that somehow.

Or we could simply allow tuples on enums where the first item is always the 
RawType of the enum?!



-- 
Adrian Zubarev
Sent with Airmail

Am 10. Oktober 2016 um 19:32:20, Kenny Leung via swift-evolution 
(swift-evolution@swift.org) schrieb:

This is the way Java enumerations work.  

https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

I think it is a good model, and I think Swift enumerations should also work the 
same way.

An enumeration is a finite set of things. It’s really inconvenient to have to 
limit those things to have only a single attribute.

-Kenny


___
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] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

> How about to a two type enums? By that I mean something like this:
>
> enum Enum : RawType, StoreType {
> case a = (rawInstance1, storeInstance1)
> case b = (rawInstance2, storeInstance2)
> case c = rawInstance3, storeInstance3 // or not tuple like?
> }
>
> let instance = Enum.a
> instance.rawValue // would be rawInstance1
> instance.value // would be storeInstance1

I think its a bit too enigmatic, and stored properties should be
explicitly defined as part of enumeration type. Just like in case of
Java enums example.

enum Format: FormatStruct {
let width: Double
let height: Double

case SMALL(width: 30, height: 30)
case MEDIUM(width: 60, height: 60)
case LARGE(width: 120, height: 120)

}

The way I see enumeration type with stored properties is something
different that enums with rawValue.

2016-10-10 20:33 GMT+02:00 Adrian Zubarev via swift-evolution
:
> I haven’t followed the whole topic, but I myself always wished for stored
> properties on Swift enums.
>
> I’d like to throw an idea in the room.
>
> How about to a two type enums? By that I mean something like this:
>
> enum Enum : RawType, StoreType {
> case a = (rawInstance1, storeInstance1)
> case b = (rawInstance2, storeInstance2)
> case c = rawInstance3, storeInstance3 // or not tuple like?
> }
>
> let instance = Enum.a
> instance.rawValue // would be rawInstance1
> instance.value // would be storeInstance1
>
> StoreType could be anything (even another two type enum).
>
> It would be interesting to read what you thing of that simple model. Plus
> should .value be mutable? Maybe we could communicate that somehow.
>
> Or we could simply allow tuples on enums where the first item is always the
> RawType of the enum?!
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 10. Oktober 2016 um 19:32:20, Kenny Leung via swift-evolution
> (swift-evolution@swift.org) schrieb:
>
> This is the way Java enumerations work.
>
> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
>
> I think it is a good model, and I think Swift enumerations should also work
> the same way.
>
> An enumeration is a finite set of things. It’s really inconvenient to have
> to limit those things to have only a single attribute.
>
> -Kenny
>
>
> ___
> 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] [Proposal] Enums with stored properties

[Kevin Nattinger via swift-evolution]

> On Oct 10, 2016, at 11:30 AM, Robert Widmann  wrote:
> 
> By imposing that kind of separation you leave an entire class of generic and 
> structural programming patterns off the table.  An enumeration is not just an 
> enumeration of constants, it is an enumeration of data, and data takes far 
> more useful forms than just bitfields

I’m not sure where you got “bitfields” from, perhaps I was unclear. I think 
enums should be a set of cases, each case having its distinct and constant set 
of data with the same structure. If one entity needs data of different, dynamic 
structure and value at runtime, that is essentially the definition of a union.

> - similarly when it does have that form it fits precisely into the form of an 
> enum with no cases?  Why artificially separate the two concepts when they’re 
> clearly one and the same?
> 
> ~Robert Widmann
> 
>> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I agree wholeheartedly. An enum case should be a compile-time constant.  
>> IMO, “enums” with associated values should properly be a separate entity, 
>> called “union” as that’s essentially what they are. 
>> 
>>> On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> This is the way Java enumerations work. 
>>> 
>>> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html 
>>> 
>>> 
>>> I think it is a good model, and I think Swift enumerations should also work 
>>> the same way.
>>> 
>>> An enumeration is a finite set of things. It’s really inconvenient to have 
>>> to limit those things to have only a single attribute.
>>> 
>>> -Kenny
>>> 
>>> 
>>> ___
>>> 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] [Proposal] Enums with stored properties

[J.E. Schotsman via swift-evolution]

> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote:
> 
> t a good illustration of what I would like to be able to define with
> my proposed feature.
> But instead to creating a class/struct to in switch case I would like
> enumeration type to be able to carry that information within its cases

Wouldn’t it be more natural to allow structs as raw values?

For example

struct MyRect
{
var height:Int
var width:Int
var area:Int {return height:Int*width}
}

enum RectSizes: MyRect
{
case Small(30,30)
case Medium(60,60)
case Large(120,120)
}

let smallArea = RectSizes.Small.rawValue.area

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

Re: [swift-evolution] [Proposal] Enums with stored properties

[Kevin Nattinger via swift-evolution]

Also, just to be clear, (unfortunately) the enum ship has sailed and I don’t 
think we’ll get a rename/split to union, it’s just that the functionality of 
associated objects is conceptually closer to what other languages call a union. 
 I would, however, like the ability to use an enum in the proper way, as a set 
of compile-time-constant data accessed in an easier way than having to use the 
ugly but currently necessary hack of `switch value { case .x: return 1; case 
.y: return 2; … }`.

> On Oct 10, 2016, at 11:52 AM, Kevin Nattinger  wrote:
> 
> 
>> On Oct 10, 2016, at 11:30 AM, Robert Widmann > > wrote:
>> 
>> By imposing that kind of separation you leave an entire class of generic and 
>> structural programming patterns off the table.  An enumeration is not just 
>> an enumeration of constants, it is an enumeration of data, and data takes 
>> far more useful forms than just bitfields
> 
> I’m not sure where you got “bitfields” from, perhaps I was unclear. I think 
> enums should be a set of cases, each case having its distinct and constant 
> set of data with the same structure. If one entity needs data of different, 
> dynamic structure and value at runtime, that is essentially the definition of 
> a union.
> 
>> - similarly when it does have that form it fits precisely into the form of 
>> an enum with no cases?  Why artificially separate the two concepts when 
>> they’re clearly one and the same?
>> 
>> ~Robert Widmann
>> 
>>> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I agree wholeheartedly. An enum case should be a compile-time constant.  
>>> IMO, “enums” with associated values should properly be a separate entity, 
>>> called “union” as that’s essentially what they are. 
>>> 
 On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 This is the way Java enumerations work. 
 
 https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html 
 
 
 I think it is a good model, and I think Swift enumerations should also 
 work the same way.
 
 An enumeration is a finite set of things. It’s really inconvenient to have 
 to limit those things to have only a single attribute.
 
 -Kenny
 
 
 ___
 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] [Proposal] Enums with stored properties

[Kevin Nattinger via swift-evolution]

I would be amenable to that IF we can skip the `.rawValue`, which is, IMO, ugly 
and repetitive.
> On Oct 10, 2016, at 11:54 AM, J.E. Schotsman via swift-evolution 
>  wrote:
> 
> 
>> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote:
>> 
>> t a good illustration of what I would like to be able to define with
>> my proposed feature.
>> But instead to creating a class/struct to in switch case I would like
>> enumeration type to be able to carry that information within its cases
> 
> Wouldn’t it be more natural to allow structs as raw values?
> 
> For example
> 
> struct MyRect
>   {
>   var height:Int
>   var width:Int
>   var area:Int {return height:Int*width}
>   }
> 
> enum RectSizes: MyRect
>   {
>   case Small(30,30)
>   case Medium(60,60)
>   case Large(120,120)
>   }
> 
> let smallArea = RectSizes.Small.rawValue.area
> 
> Jan E.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

For simple structs this is already possible (see this example:
https://swiftlang.ng.bluemix.net/#/repl/57fb8e3e4f9bcf25fdd415cd).
If we focus on more complex cases where properties of Any? type are
allowed I think this approach could do the trick...
but still I would like to be able to access properties without using rawValue
--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info


2016-10-10 20:54 GMT+02:00 J.E. Schotsman via swift-evolution
:
>
> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote:
>
>
> t a good illustration of what I would like to be able to define with
> my proposed feature.
> But instead to creating a class/struct to in switch case I would like
> enumeration type to be able to carry that information within its cases
>
>
> Wouldn’t it be more natural to allow structs as raw values?
>
> For example
>
> struct MyRect
> {
> var height:Int
> var width:Int
> var area:Int {return height:Int*width}
> }
>
> enum RectSizes: MyRect
> {
> case Small(30,30)
> case Medium(60,60)
> case Large(120,120)
> }
>
> let smallArea = RectSizes.Small.rawValue.area
>
> Jan E.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Tony Constantinides via swift-evolution]

Ok,
 I was trying to follow the evolution process which states to "discuss your
idea on the mailing lists" before i begin work on it.That is what I am
doing. If you feel this work is not part of swift-evolution I shall bother
this group no longer.  You have to remember I am very new to interfacing
with the Swift team hence the cautious approach. I do realize this is a
proposal and not a pitch and I am prepare to provide a great many more
details in a proposal. If you wish to point me to another swift mailing
list then please do so. If you feel this a "third party lib" then tell me
where it slots in. In other words be helpful and not react like a teen age
girl.
  Of course I will begin development of this feature on github and give
talks to my local developer group. When I create a github with this
framework I going to have to add a licence.  Making the software
copyrighted to my company and not link to the swift.org project in any way
seem odd to me. Not my idea of "open source" or contributing to a "major
open source project". You state that the Swift community members have spent
a great deal of time and effort in getting getting Swift to even build on
Android. Congrats! I here to take it to the next level.
 If there is Swift community interest the code will be free via open
source. If there is none and judging by the response from the developers in
my "Bay Area Android Developer meetup group" that hard to believe then I
make it it commercial software to be sold.
 Many thanks in advance.
Sincerely yours,
Tony Constantinides






On Mon, Oct 10, 2016 at 11:15 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> It’s disappointing that you seem not to understand what this mailing list
> is for. Building a Framework does not require the evolution process. It’s
> all up to you to open a GitHub repository and just start building.
>
> Sure you can ask for help, but I believe other platforms like
> stackoverflow or even swift-users would be a better place for that.
>
> And I think your statement about rejection is totally wrong. The core team
> has enough work and responsibility to care about.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 10. Oktober 2016 um 20:06:26, Tony Constantinides via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> I find it extremely disappointing if Swift core members reject enhancing
> Swift to target additional mobile platforms as making Swift cross-platform
> is a stated goal.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

Right. The question is whether we *need* to add stored properties 
out-of-module, and what the use case for that is. To me it seems that adding 
them in-module is by far the more common use case, for the purposes of 
implementing protocols.

At any rate, the rewrite option would be a great addition to Swift regardless 
of what our answer to the first question is.

Charles

> On Oct 9, 2016, at 4:32 PM, Jay Abbott  wrote:
> 
> Charles,
> 
> That would be good. It is a nicer way to write what is already possible to 
> achieve, but it's not a way to 'implement' stored properties in extensions.
> 
> On Sun, 9 Oct 2016 at 21:45 Charles Srstka  > wrote:
> *Replace both instances of “class C: P” with just “class C” since the 
> conformance comes in the extension. That’s what I get for writing this 
> quickly.
> 
> Charles
> 
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka > > wrote:
>> 
>> protocol P {
>>  var foo: String { get }
>>  func bar()
>> }
>> 
>> protocol Q {
>>  var baz: Int { get }
>>  func qux()
>> }
>> 
>> class C: P {
>>  var foo: String // <- what is this doing here?
>>  var baz: Int // <- ditto
>> }
>> 
>> extension C: P {
>>  func bar() {}
>> }
>> 
>> extension C: Q {
>>  func qux() {}
>> }
>> 
>> we could simply:
>> 
>> protocol P {
>>  var foo: String { get }
>>  func bar()
>> }
>> 
>> class C: P {}
>> 
>> extension C: P {
>>  var foo: String
>>  func bar() {}
>> }
>> 
>> extension C: Q {
>>  var baz: Int
>>  func qux() {}
>> }
> 

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

Re: [swift-evolution] [Proposal] Enums with stored properties

[Haravikk via swift-evolution]

> On 10 Oct 2016, at 14:36, Mateusz Malczak  wrote:
> 
>> Can't this problem most easily be solved by a raw value? Like so:
>> 
>> enum Format : Int {
>>case small = 30
>>case medium = 60
>>case large = 120
>> 
>>var width:Int { return self.rawValue }
>>var height:Int { return self.rawValue }
>> }
> 
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
> 
> --
> | Mateusz Malczak

I know, but what I'm saying is that this problem could be solved in the 
multiple values case by allowing tuples as raw values for enums, since that 
would allow you to specify both width and height. So it'd look something like 
this:

enum Format : (width:Int, height:Int) {
case small = (30, 30)
case medium = (60, 60)
case large = (120, 120)

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

This currently isn't supported as tuples aren't treated as a literal type, even 
when composed of literal types.

Since enum values can be anything that is representable as literal (except 
arrays, apparently, which I tried but don't seem to work), you can implement 
this with a lot of boiler-plate like so:

struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable {
let width:Int, height:Int
init(width:Int, height:Int) { self.width = width; self.height = height }

init(extendedGraphemeClusterLiteral:String) { self.init(rawValue: 
extendedGraphemeClusterLiteral)! }
init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
init(unicodeScalarLiteral:String) { self.init(rawValue: 
unicodeScalarLiteral)! }

var rawValue:String { return "\(self.width),\(self.height)" }
init?(rawValue:String) { let parts = rawValue.components(separatedBy: ","); 
self.width = Int(parts[0])!; self.height = Int(parts[1])! }
}
func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width == 
rhs.width) && (lhs.height == rhs.height) }

enum Format : Dimensions {
case small = "30,30"
case medium = "60,60"
case large = "120,120"

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

Not at all pretty, but it works (and I believe the string parsing should 
optimise away in practice).

Anyway, my point is that the best solution to the problem you're trying to 
solve would be to expand the enum raw value support to include tuples.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

> I know, but what I'm saying is that this problem could be solved in the
> multiple values case by allowing tuples as raw values for enums, since that
> would allow you to specify both width and height. So it'd look something
> like this:

We have three different possible solution
1. stored properties defined as part of enumeration type
enum RectSizes: MyRect
{
let height:Int
let width:Int
case Small(width: 30, height: 30)
case Medium(width: 60, height: 60)
case Large(width: 120, height: 120)
}

2. struct as rawValue
struct MyRect
{
var height:Int
var width:Int
var area:Int {return height:Int*width}
}

enum RectSizes: MyRect
{
case Small(30,30)
case Medium(60,60)
case Large(120,120)
}

3. tuples as rawValue
enum Format : (width:Int, height:Int) {
case small(30, 30)
case medium(60, 60)
case large(120, 120)

var width:Int { return self.rawValue.width }
var height:Int { return self.rawValue.height }
}

Solutions 2 and 3 are quire similar, to get value of a stored property
we need to use rawValue or define value getters. In addition in
solution 2 we define an additional data type just to be used as an
enumeration type rawValue type. In my opinion, first approach would be
a best solution, type definition is clear and self-explanatory because
it is similar to how enums/classes are defined.


--
| Mateusz Malczak
+---


2016-10-10 21:18 GMT+02:00 Haravikk :
>
> On 10 Oct 2016, at 14:36, Mateusz Malczak  wrote:
>
> Can't this problem most easily be solved by a raw value? Like so:
>
> enum Format : Int {
>case small = 30
>case medium = 60
>case large = 120
>
>var width:Int { return self.rawValue }
>var height:Int { return self.rawValue }
> }
>
>
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
>
> --
> | Mateusz Malczak
>
>
> I know, but what I'm saying is that this problem could be solved in the
> multiple values case by allowing tuples as raw values for enums, since that
> would allow you to specify both width and height. So it'd look something
> like this:
>
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
>
> This currently isn't supported as tuples aren't treated as a literal type,
> even when composed of literal types.
>
> Since enum values can be anything that is representable as literal (except
> arrays, apparently, which I tried but don't seem to work), you can implement
> this with a lot of boiler-plate like so:
>
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable
> {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
>
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue:
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue:
> unicodeScalarLiteral)! }
>
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy:
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width ==
> rhs.width) && (lhs.height == rhs.height) }
>
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
> Not at all pretty, but it works (and I believe the string parsing should
> optimise away in practice).
>
> Anyway, my point is that the best solution to the problem you're trying to
> solve would be to expand the enum raw value support to include tuples.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Marinus van der Lugt via swift-evolution]

> On 10 Oct 2016, at 21:18, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 10 Oct 2016, at 14:36, Mateusz Malczak > > wrote:
>> 
>>> Can't this problem most easily be solved by a raw value? Like so:
>>> 
>>> enum Format : Int {
>>>case small = 30
>>>case medium = 60
>>>case large = 120
>>> 
>>>var width:Int { return self.rawValue }
>>>var height:Int { return self.rawValue }
>>> }
>> 
>> This only solves a problem when width/height are the same. Im talking
>> here about more general use case when you can assign different values
>> of different types to an enum case. Please refer to the example code:
>> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8 
>> 
>> 
>> --
>> | Mateusz Malczak
> 
> I know, but what I'm saying is that this problem could be solved in the 
> multiple values case by allowing tuples as raw values for enums, since that 
> would allow you to specify both width and height. So it'd look something like 
> this:
> 
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
> 
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
> 
> This currently isn't supported as tuples aren't treated as a literal type, 
> even when composed of literal types.
> 

Nice, that ties in well with a recent post here about deriving enums from other 
types:

struct Size {
   let width: Double
   let height: Double
}

enum Format: Size {
   case small = Size(width: 30, height: 30)
   case medium = Size(width: 60, height: 60)
}

let format = Format.small
let size = format.width

I’d like that a lot!


> Since enum values can be anything that is representable as literal (except 
> arrays, apparently, which I tried but don't seem to work), you can implement 
> this with a lot of boiler-plate like so:
> 
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
> 
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue: 
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue: 
> unicodeScalarLiteral)! }
> 
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy: 
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width == 
> rhs.width) && (lhs.height == rhs.height) }
> 
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
> 
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
> 
> Not at all pretty, but it works (and I believe the string parsing should 
> optimise away in practice).
> 
> Anyway, my point is that the best solution to the problem you're trying to 
> solve would be to expand the enum raw value support to include tuples.
> ___
> 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] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

Yes, there are valid use cases. 

For example, in case of many UI elements, you do not have control over their 
instantiation and need to associate a "help description" with them as an 
example. Which can be done by an additional property helpDescription added to 
NSView/UIView.

Another example that I've used is with CoreData, where you can store additional 
information on the MOC - NSManagedObjectContext is strongly discouraged from 
being subclassed. Example of the additional information is a synchronization 
manager assigned to the MOC.

And since in Swift, classes can be final, there may not be a way to subclass 
the class to add your properties instead.

IMHO, it is a valid request to be able to add additional stored properties via 
extensions.

> On Oct 10, 2016, at 9:15 PM, Charles Srstka  wrote:
> 
> Right. The question is whether we *need* to add stored properties 
> out-of-module, and what the use case for that is. To me it seems that adding 
> them in-module is by far the more common use case, for the purposes of 
> implementing protocols.
> 
> At any rate, the rewrite option would be a great addition to Swift regardless 
> of what our answer to the first question is.
> 
> Charles
> 
>> On Oct 9, 2016, at 4:32 PM, Jay Abbott > > wrote:
>> 
>> Charles,
>> 
>> That would be good. It is a nicer way to write what is already possible to 
>> achieve, but it's not a way to 'implement' stored properties in extensions.
>> 
>> On Sun, 9 Oct 2016 at 21:45 Charles Srstka > > wrote:
>> *Replace both instances of “class C: P” with just “class C” since the 
>> conformance comes in the extension. That’s what I get for writing this 
>> quickly.
>> 
>> Charles
>> 
>>> On Oct 9, 2016, at 3:43 PM, Charles Srstka >> > wrote:
>>> 
>>> protocol P {
>>> var foo: String { get }
>>> func bar()
>>> }
>>> 
>>> protocol Q {
>>> var baz: Int { get }
>>> func qux()
>>> }
>>> 
>>> class C: P {
>>> var foo: String // <- what is this doing here?
>>> var baz: Int // <- ditto
>>> }
>>> 
>>> extension C: P {
>>> func bar() {}
>>> }
>>> 
>>> extension C: Q {
>>> func qux() {}
>>> }
>>> 
>>> we could simply:
>>> 
>>> protocol P {
>>> var foo: String { get }
>>> func bar()
>>> }
>>> 
>>> class C: P {}
>>> 
>>> extension C: P {
>>> var foo: String
>>> func bar() {}
>>> }
>>> 
>>> extension C: Q {
>>> var baz: Int
>>> func qux() {}
>>> }
>> 
> 

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

Re: [swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

[Dave Abrahams via swift-evolution]

on Mon Oct 10 2016, Tony Constantinides  wrote:

> Its a nice cop-out, but this framework is an extension of the standard
> library of Swift as it will allow Swift developers to target new mobile
> platforms. 

It's not a cop-out.  We would never include UIKit in Swift's standard
library, which is the set of definitions you get without so much as an
“import”.  UI functionality simply belongs elsewhere.

> This is the mailing lists for the evolution of Swift which is what
> this is. I not sure any of the other Swift mailing lists suits this
> goal. I not making Swift language changes(maybe) but adding an
> additional library that developers can build against if they are
> interested in having their Swift code running on Android.
>
> Note that the Swift project itself has provided documentation and hooks to
> provide this capabailit seen here
> https://github.com/apple/swift/blob/master/docs/Android.md
> The main issue is that swiftcore is missing on Swift for Linux.
>
>   Its only important to understand I going to build this framework with or
> without support from Swift.org. However I want other developers to benefit
> from my work and I want to give back to the community. I find it extremely
> disappointing if Swift core members reject enhancing Swift to target
> additional mobile platforms as making Swift cross-platform is a stated goal.
>
> On Mon, Oct 10, 2016 at 9:41 AM, Douglas Gregor 
> wrote:
>
>>
>> > On Oct 9, 2016, at 9:45 PM, Tony Constantinides via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > In Swift 3.0 you can build Android apps in Linux but only console apps
>> as there is no framework to build GUI apps using JNI.
>> > What I propose is to build an initial limited framework coded in C that
>> calls enough of the Java Android API via JNI to bootstrap the android app
>> and to create widgets and layouts.A default Androidmanifest.xml file and
>> some files needed to be generated to make a valid android app.
>> >   The Android API java surface is vast, so this framework needs to be
>> build over many releases to be useful. Developing a graphical Android app
>> requires interaction with "Activities" and the package manager and some
>> widgets like Button and some layouts like "RelativeLayout" and
>> "LinearLayout".
>> >  The result will be the ability to develop GUI Android apps on Linux
>> using Swift 3.0
>> > Further support for additional APIs will be provided once the basics are
>> solid..
>> > Who am I: Senior Android mobile developer with more than six years
>> experience on Android.
>> > Am I able to build Swift 3.0 on Linux: Yes
>>
>> The swift-evolution process is primarily focused on the Swift language and
>> standard library. Large-scale API development, which binding to/creating a
>> GUI library entails, is out-of-scope for this process and should occur in a
>> different forum.
>>
>> Cheers,
>> Doug
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave

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

Re: [swift-evolution] Automatic generation of initializer including default values

[Matthew Johnson via swift-evolution]

We considered a proposal I wrote early in the year.  There was extensive 
discussion of the topic at that time.  The core team decided to defer the topic 
at the time.  Everyone was convinced there are better ways to handle it than I 
originally proposed (including myself).  The topic will be revisited at some 
point in the future but is not in scope for Swift 4, phase 1.

If you wish to catch up on the discussion, here’s a link to the proposal which 
includes links to the discussion as well as the core team’s rationale for their 
decision on this proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md
 



> On Oct 10, 2016, at 7:27 AM, Guy Miller via swift-evolution 
>  wrote:
> 
> Hi,
> 
> When I am defining a struct I find myself often using a style as shown in the 
> following example:
> 
> struct Foo {
> 
>   var greeting: String
>   var x: Int
>   var y: Int
>   var z: Int
> 
>   init(greeting: String, x: Int = 1, y: Int = 2, z: Int = 3) {
>   self.greeting = greeting
>   self.x = x
>   self.y = y
>   self.z = z
>   }
> }
> 
> This enables one to write code when one doesn’t need to change defaults:
> 
> let f = Foo(greeting: “Hello”)
> 
> and when one wishes to change one of the defaults:
> 
> let f = Foo(greeting: “Hello”, z: 4)
> 
> It would be better if one could write the struct in what I understand is the 
> preferred style:
> 
> struct Foo {
>   var greeting: String
>   var x = 1
>   var y = 2
>   var z = 3
> }
> 
> and have the compiler generate the initializer:
> 
> init(name: String, x: Int = 1, y: Int = 2, z: Int = 3) {
>   self.name = name
>   self.x = x
>   self.y = y
>   self.z = z
> }
> 
> rather than one where all the parameters that have a default value need to be 
> specified in the initializer if one wishes to change just one of them.
> 
> Regards,
> Guy Miller
> 
> 
> 
> 
> ___
> 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] [Proposal] Enums with stored properties

[Mateusz Malczak via swift-evolution]

I just did a quick summary of this discussion and get all ideas and
code examples in one place -
https://github.com/malczak/enums-with-stored-properties

I will try to keep that document updated, but feel free to edit it as well

--
| Mateusz Malczak


2016-10-10 21:18 GMT+02:00 Haravikk :
>
> On 10 Oct 2016, at 14:36, Mateusz Malczak  wrote:
>
> Can't this problem most easily be solved by a raw value? Like so:
>
> enum Format : Int {
>case small = 30
>case medium = 60
>case large = 120
>
>var width:Int { return self.rawValue }
>var height:Int { return self.rawValue }
> }
>
>
> This only solves a problem when width/height are the same. Im talking
> here about more general use case when you can assign different values
> of different types to an enum case. Please refer to the example code:
> https://swiftlang.ng.bluemix.net/#/repl/57fb98074f9bcf25fdd415d8
>
> --
> | Mateusz Malczak
>
>
> I know, but what I'm saying is that this problem could be solved in the
> multiple values case by allowing tuples as raw values for enums, since that
> would allow you to specify both width and height. So it'd look something
> like this:
>
> enum Format : (width:Int, height:Int) {
> case small = (30, 30)
> case medium = (60, 60)
> case large = (120, 120)
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
>
> This currently isn't supported as tuples aren't treated as a literal type,
> even when composed of literal types.
>
> Since enum values can be anything that is representable as literal (except
> arrays, apparently, which I tried but don't seem to work), you can implement
> this with a lot of boiler-plate like so:
>
> struct Dimensions : RawRepresentable, ExpressibleByStringLiteral, Equatable
> {
> let width:Int, height:Int
> init(width:Int, height:Int) { self.width = width; self.height = height }
>
> init(extendedGraphemeClusterLiteral:String) { self.init(rawValue:
> extendedGraphemeClusterLiteral)! }
> init(stringLiteral:String) { self.init(rawValue: stringLiteral)! }
> init(unicodeScalarLiteral:String) { self.init(rawValue:
> unicodeScalarLiteral)! }
>
> var rawValue:String { return "\(self.width),\(self.height)" }
> init?(rawValue:String) { let parts = rawValue.components(separatedBy:
> ","); self.width = Int(parts[0])!; self.height = Int(parts[1])! }
> }
> func == (lhs:Dimensions, rhs:Dimensions) -> Bool { return (lhs.width ==
> rhs.width) && (lhs.height == rhs.height) }
>
> enum Format : Dimensions {
> case small = "30,30"
> case medium = "60,60"
> case large = "120,120"
>
> var width:Int { return self.rawValue.width }
> var height:Int { return self.rawValue.height }
> }
>
> Not at all pretty, but it works (and I believe the string parsing should
> optimise away in practice).
>
> Anyway, my point is that the best solution to the problem you're trying to
> solve would be to expand the enum raw value support to include tuples.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with stored properties

[Haravikk via swift-evolution]

> On 10 Oct 2016, at 20:34, Mateusz Malczak  wrote:
> 
>> I know, but what I'm saying is that this problem could be solved in the
>> multiple values case by allowing tuples as raw values for enums, since that
>> would allow you to specify both width and height. So it'd look something
>> like this:
> 
> We have three different possible solution
> 1. stored properties defined as part of enumeration type
> enum RectSizes: MyRect
> {
>let height:Int
>let width:Int
>case Small(width: 30, height: 30)
>case Medium(width: 60, height: 60)
>case Large(width: 120, height: 120)
> }
> 
> 2. struct as rawValue
> struct MyRect
> {
>var height:Int
>var width:Int
>var area:Int {return height:Int*width}
> }
> 
> enum RectSizes: MyRect
> {
>case Small(30,30)
>case Medium(60,60)
>case Large(120,120)
> }
> 
> 3. tuples as rawValue
> enum Format : (width:Int, height:Int) {
>case small(30, 30)
>case medium(60, 60)
>case large(120, 120)
> 
>var width:Int { return self.rawValue.width }
>var height:Int { return self.rawValue.height }
> }
> 
> Solutions 2 and 3 are quire similar, to get value of a stored property
> we need to use rawValue or define value getters. In addition in
> solution 2 we define an additional data type just to be used as an
> enumeration type rawValue type. In my opinion, first approach would be
> a best solution, type definition is clear and self-explanatory because
> it is similar to how enums/classes are defined.
> 
> 
> --
> | Mateusz Malczak

Actually I'd say your option 2 here is more similar to option 1 (you seem to be 
using a struct to define the stored properties instead). The issue here is that 
storing properties conflicts with what you're actually doing, which is storing 
case-specific values, which is what rawValue already does, it's just too 
limited for your current use-case (multiple values).

The complete solution would be to introduce the concept of tuples as literals 
(even though they can't currently conform to types); this would make it a lot 
easier to support the use of any type as a fixed value for each case (not just 
tuples). For example, say we introduced as new protocol:

protocol ExpressableByTuple {
associatedtype TupleType // somehow force this to be a tuple or 
ExpressableByType type
init(tupleLiteral:TupleType)
}

With a bit of magic all tuples could conform to this protocol with themselves 
as the literal type, allowing us to use them as enum raw values; likewise this 
could then be used to more easily enable any custom struct/class for storage in 
enum cases, as instead of supporting their constructors directly we can just 
support construction via a tuple literal.


My other reason I don't favour option 1, while it looks a bit prettier, is that 
it's a bit confusing; enums have two types of stored properties, ones that can 
be changed (and inspected) which is what you get when you declare case 
small(Int, Int) for example, these are stored as part of the enum itself (so in 
that example it's 17-bytes on a 64-bit system). However rawValues are more like 
constants/static values, and don't increase the size of the type, and I just 
feel that this is the right way to do what you're proposing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] deprecating ManagedBufferPointer

[Erik Eckstein via swift-evolution]

The purpose of ManagedBufferPointer is to create a buffer with a custom 
class-metadata to be able to implement a custom deinit (e.g. to destroy the 
tail allocated elements).
It was used in Array (before I replaced it with the new 
tail-allocated-array-built-ins). But now it’s not used anymore in the standard 
library.

As a replacement for ManagedBufferPointer one can just derive a class from 
ManagedBuffer and implement the deinit in the derived class.

final class MyBuffer : ManagedBuffer {
  deinit {
// do whatever needs to be done
  }
}

// creating MyBuffer:
let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in return 
MyHeader(...) })

IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t need 
this custom bufferClass to be passed to the constructor). Also 
ManagedBufferPointer doesn’t use SIL tail-allocated arrays internally. Although 
this is not something visible to the programmer, it makes life easier for the 
compiler.

So I suggest that we deprecate ManagedBufferPointer.

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

Re: [swift-evolution] private & fileprivate

[Chris Lattner via swift-evolution]

On Oct 8, 2016, at 12:15 PM, Matthew Johnson via swift-evolution 
 wrote:
> 
> There are rather significant optimization barriers at module boundaries right 
> now.  These do not exist for the standard library due to its tight 
> relationship with the compiler, but for the moment it is a non-trivial 
> concern for 3rd party code that is performance sensitive.  This is 
> effectively a language pressure in the direction of larger modules, at least 
> for some domains.  (Hopefully this pressure will eventually be alleviated - 
> there has been at least some talk in that direction)

Indeed, I expect that this will be a big focus over the next year.  The 
resilience model and ABI stability drive the urgency of getting this worked out.

-Chris

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

[swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

[Tim Vermeulen via swift-evolution]

There have been many instances where unexpected bad performance was caused by 
the interplay between getters, setters, mutations and the copy-on-write 
mechanism. For example:

struct Foo {
private var _array: [Int] = [1, 2, 3, 4, 5]

var array: [Int] {
get { return _array }
set { _array = newValue }
}
}

var foo = Foo()
foo.array.append(6) // an O(n) operation

I propose a `mutate` clause which provides a `mutate` function with a single 
inout parameter (similar to how `set` provides `newValue`), which can be used 
instead of a setter:

var array: [Int] {
get { return _array }
mutate { mutate(&_array) }
}

The compiler could then translate each mutation of `foo.array` to a closure 
with an inout parameter, which is then passed into the `mutate` clause (which 
in turn is executed with `_array` as its argument, as per the snippet above). 
For example, for `foo.array.append(6)`, the compiler would internally generate 
the closure `{ (arr: inout [Int]) in arr.append(6) }` and pass it into the 
`mutate` clause, `_array` is then passed as its parameter and the array is 
updated in constant time.

I apologise if that was too hard to follow.

No setter would be needed if a mutation clause is provided, but I see no good 
reason to do away with setters altogether, so this proposal would be purely 
additive.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

[Erica Sadun via swift-evolution]

> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution 
>  wrote:
> 
> There have been many instances where unexpected bad performance was caused by 
> the interplay between getters, setters, mutations and the copy-on-write 
> mechanism. For example:
> 
> struct Foo {
> private var _array: [Int] = [1, 2, 3, 4, 5]
> 
> var array: [Int] {
> get { return _array }
> set { _array = newValue }
> }
> }
> 
> var foo = Foo()
> foo.array.append(6) // an O(n) operation
> 
> I propose a `mutate` clause which provides a `mutate` function with a single 
> inout parameter (similar to how `set` provides `newValue`), which can be used 
> instead of a setter:
> 
> var array: [Int] {
> get { return _array }
> mutate { mutate(&_array) }
> }
> 
> The compiler could then translate each mutation of `foo.array` to a closure 
> with an inout parameter, which is then passed into the `mutate` clause (which 
> in turn is executed with `_array` as its argument, as per the snippet above). 
> For example, for `foo.array.append(6)`, the compiler would internally 
> generate the closure `{ (arr: inout [Int]) in arr.append(6) }` and pass it 
> into the `mutate` clause, `_array` is then passed as its parameter and the 
> array is updated in constant time.
> 
> I apologise if that was too hard to follow.
> 
> No setter would be needed if a mutation clause is provided, but I see no good 
> reason to do away with setters altogether, so this proposal would be purely 
> additive.

If this is computationally better, why is it not the default behavior rather 
than an API change?

-- E


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

Re: [swift-evolution] private & fileprivate

[David Waite via swift-evolution]

Unfortunately, my agreement may come off a bit backhanded. IMHO, the 
“fileprivate” problem is due to SE-0025 trying to add sophistication to access 
control too fast. 

My observation is that Swift developers as a whole really have not yet come to 
a conclusion that the permissions already present in the language were truly 
insufficient for large scale software development.  More so, *how* they are 
insufficient wasn’t clearly represented - for instance, I’ve heard complaints 
that files become too large by having to bundle dependent extensions and 
classes, but SE-0025 did little to target their desire for a more manageable 
codebase. Instead, it allows them to make sections of those large files “more 
private”.

I’m convinced as the Swift language and other Swift-based projects both gain 
more maturity, we will be able to get a holistic view of how access control 
should work and how it should correlate to project structure. Before then, any 
change may simply do more harm than good.

-DW

> On Oct 10, 2016, at 10:59 AM, Douglas Gregor via swift-evolution 
>  wrote:
>> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
 On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Beyond the textual change of using a different modifier name, I don’t see 
>>> how the encapsulation and organization of code could be affected. Really, 
>>> there’s not much point in rehashing prior discussion of SE-0025 unless 
>>> there’s a previously unconsidered angle.
>> 
>> I strongly agree with this sentiment. SE-0025 was very heavily discussed, 
>> and while many people were not satisfied with the solution we went with 
>> (including me!), it was what the core team and community converged on. I 
>> don't expect us to change access control again until and unless we decide to 
>> change the model in some way, and even then I think we'll want to go through 
>> extra effort to maintain compatibility with Swift 3. As has been mentioned 
>> repeatedly, the bar for source-breaking changes is much higher than it was 
>> in the first few months of swift-evolution.
>> 
>> I actually consider it very lucky that most of our changes so far have been 
>> fairly non-controversial. Everybody has a different idea of what would make 
>> Swift a better language, and all of us well-meaning. But when those ideas 
>> conflict, some group is going to end up unhappy. I'm actually very glad that 
>> (a) we haven't had too many of these cases, and (b) even when we have, 
>> people have been able to accept it and move on to contributing to the next 
>> issue.
> 
> 
> Strong agreement here as well. This proposal has been litigated numerous 
> times already, and the bar for source-breaking changes is much higher now. To 
> effectively re-open the discussion would require a proposal that significant 
> changes the model with a lot of evidence that such a new model is a drastic 
> improvement over what we have now. “Back out SE-0025” is not a viable option 
> now.
> 
>   - Doug
> 
> ___
> 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] [Pitch] Change location of 'try' for infix operators

[Karl via swift-evolution]

You might expect this code to work:

func aFunction() -> Int?   { return 5 }
func bFunction() throws -> Int { return 4 }

let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but 
expression is not marked with a ‘try'
print(value)

Instead, you must put the ‘try’ before the entire expression:

let value = try aFunction() ?? bFunction()

This is awkward, since aFunction() doesn’t throw.
I propose we change the grammar to allow the first example and disallow the 
second, consistent with the idea that throwing calls are ‘marked’ by using the 
try keyword.

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

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

[Ben Rimmington via swift-evolution]

> On 11 Oct 2016, at 07:16, Karl wrote:
> 
> You might expect this code to work:
> 
> func aFunction() -> Int?   { return 5 }
> func bFunction() throws -> Int { return 4 }
> 
> let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but 
> expression is not marked with a ‘try'
> print(value)
> 
> Instead, you must put the ‘try’ before the entire expression:
> 
> let value = try aFunction() ?? bFunction()
> 
> This is awkward, since aFunction() doesn’t throw.
> I propose we change the grammar to allow the first example and disallow the 
> second, consistent with the idea that throwing calls are ‘marked’ by using 
> the try keyword.

The `??` function rethrows an error from its rhs operand.

@_transparent
public func ?? (optional: T?, defaultValue: @autoclosure () throws 
-> T)
rethrows -> T {
  switch optional {
  case .some(let value):
return value
  case .none:
return try defaultValue()
  }
}



-- Ben

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

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

[Benjamin Spratling via swift-evolution]

Howdy,
The error message is not saying that aFunction throws, it says “??" might 
throw.  After all, you supplied a ()rethrows->(Int) to it as its second 
argument, which is wrapping a ()throws->Int, “bFunction()"
?? and && and || wrap the trailing expression in an @autoclosure.

I am a little surprised two “try” are not required.  This would be my 
expectation:
> let value = try aFunction() ?? try bFunction()
but, using try to the right of a non-assignment operator is not allowed.

This, however, is not disallowed:

let value = try aFunction() ?? (try bFunction())

The purpose of the @autoclosure is to make developers forget they need to write 
a closure, and it apparently worked for you.

-Ben Spratling


> On Oct 11, 2016, at 1:16 AM, Karl via swift-evolution 
>  wrote:
> 
> You might expect this code to work:
> 
> func aFunction() -> Int?   { return 5 }
> func bFunction() throws -> Int { return 4 }
> 
> let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but 
> expression is not marked with a ‘try'
> print(value)
> 
> Instead, you must put the ‘try’ before the entire expression:
> 
> let value = try aFunction() ?? bFunction()
> 
> This is awkward, since aFunction() doesn’t throw.
> I propose we change the grammar to allow the first example and disallow the 
> second, consistent with the idea that throwing calls are ‘marked’ by using 
> the try keyword.
> 
> 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