[swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[Douglas Gregor via swift-evolution]

Hi all,

Currently, producing an Objective-C selector in Swift is an error-prone 
operation. One effectively just writes a string literal and uses it in a 
context where an ObjectiveC.Selector is expected:

control.sendAction(“doSomething:”, to: target, forEvent: event)

There are many points of failure here:

1) The compiler doesn’t syntax-check at all to make sure it’s a valid spelling 
for a selector
2) The compiler doesn’t look for existing methods with this selector anywhere
3) The mapping from a Swift method name to an Objective-C selector isn’t always 
immediately obvious (especially for initializers), and will be getting 
significantly more complicated with the renaming work for Swift 3 
(https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md).

I suggest that we add an expression ‘objc_selector(method-reference)` that 
produces the Objective-C selector for the named method, and produces an error 
if the method does not have an Objective-C entry point. For example:

control.sendAction(objc_selector(MyApplication.doSomething), to: 
target, forEvent: event)

“doSomething” is a method of MyApplication, which might even have a 
completely-unrelated name in Objective-C:

extension MyApplication {
@objc(jumpUpAndDown:)
func doSomething(sender: AnyObject?) { … }
}

By naming the Swift method and having objc_selector do the work to form the 
Objective-C selector, we free the programming from having to do the naming 
translation manually and get static checking that the method exists and is 
exposed to Objective-C.

This proposal composes with my “Generalized Naming for Any Function” proposal, 
which lets us name methods fully, including getters/setters:

let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // 
produces the Selector “insertSubview:atIndex:"
let sel2: Selector = objc_selector(UIView.`frame.get`) // produces the 
Selector “frame"

I don’t like the `objc_selector` syntax at all, but otherwise I think this 
functionality is straightforward.

- Doug

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

> On Dec 26, 2015, at 11:43 PM, Brent Royal-Gordon  
> wrote:
> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
> 
> This link doesn't work; in fact, you don't seem to have *any* public 
> repositories.

Ah, thanks. I’ve made the repository public.

- Doug

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Brent Royal-Gordon via swift-evolution]

> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md

This link doesn't work; in fact, you don't seem to have *any* public 
repositories.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

[Douglas Gregor via swift-evolution]

FYI, I just sent a proposal draft titled “Generalized Naming for Any Function” 
that pulls these ideas together more formally. I went with a different syntax 
that I’d been kicking around for a while internally, and I’d love to hear 
everyone’s thoughts on this.

- Doug

> On Dec 14, 2015, at 12:25 AM, Pierre Monod-Broca via swift-evolution 
>  wrote:
> 
> +1
> 
> I like the #get, #set suffixes.
> 
> I’m afraid the following would be a bit ambiguous
>>  - example.init(argument:Int, another:String)
>>  - example.subscript(index:Int)
> 
> Maybe with ‘#’ too
>  - example.init#argument:Int#another:String
>  - example.init#argument#another
>  - example.init#(argument:Int, another:String)
>  - example.subscript#index:Int
>  - example.subscript#Int
> 
> Pierre
> 
>> Le 14 déc. 2015 à 08:57, ilya via swift-evolution > > a écrit :
>> 
>> > Being able to refer to getters and setters is a good idea and aligns with 
>> > being able to refer to initializers and methods.
>> > I would also add subscripts to the list if possible.
>> 
>> Great idea! Let's discuss syntax
>> 
>> How about 
>>  - example.get.member
>>  - example.set.member
>>  - example.init(argument:Int, another:String)
>>  - example.subscript(index:Int)
>> 
>> 
>> On Mon, Dec 14, 2015 at 3:49 AM, Marc Knaup via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Wait, where is stated that KVO is a long-term goal for Swift? I might have 
>> missed that.
>> 
>> I find that one of Objective-C's most annoying features. It makes it really 
>> difficult to reason about code when things can happen unexpectedly left and 
>> right. It's the same issue with aspect-oriented programming.
>> 
>> I prefer explicit integration points like closures, delegates and alike.
>> Most times I used KVO in the past was to work around bugs or annoyances on 
>> iOS, like for example forcing a button stay enabled even when iOS disables 
>> it.
>> 
>> Also it's unlikely that all mutable properties will support observation 
>> automatically. That would require the optimizer to keep using dynamic 
>> dispatch for all of them which will hurt performance.
>> 
>> 
>> But I'm getting off-topic since your discussion is not about KVO nor about 
>> KVC.
>> 
>> Being able to refer to getters and setters is a good idea and aligns with 
>> being able to refer to initializers and methods.
>> I would also add subscripts to the list if possible.
>> 
>> On Mon, Dec 14, 2015 at 1:34 AM, Michael Henson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Swift-like full KVO/KVC as in Objective-C is a stated long-term goal for 
>> Swift's evolution. The 90% solution might be more straightforward:
>> 
>> class Example {
>>   var member: String
>> 
>>   func print() {
>> print(self.member)
>>   }
>> }
>> 
>> var example = Example(member: "Hi!")
>> 
>> var example_print_method = example.print
>> example_print_method()
>> result:
>> Hi!
>> 
>> If there were a mechanism for referring to the getter and setter methods on 
>> the var member property as the same kind of self-capturing closures, it 
>> could make simple cases of data binding easier to implement:
>> 
>> var serializeFields = [
>>   "member": example.member#get,
>> ]
>> 
>> var deserializeFields = [
>>   "member": example.member#set,
>> ]
>> 
>> var broadcastValueTo = [
>>   "memberValues": [
>>  example.member#set,
>>  example2.member#set,
>>  example3.member#set,
>>   ]
>> ]
>> 
>> viewController.textField.onValueChanged(example.member#set)
>> 
>> Etc.
>> 
>> The "#" notation is just a placeholder for "whatever mechanism is decided 
>> upon", though it does seem to be available and using it postfix makes a 
>> first-glance sense to me in terms of the semantics of expressions.
>> 
>> Mike
>>  
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>>  
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@s

[swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Hi all,

Here’s a proposal draft to allow one to name any function in Swift. In effect, 
it’s continuing the discussion of retrieving getters and setters as functions 
started by Michael Henson here:


https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html

the proposal follows, and is available here as well:


https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md

Comments appreciated!

Generalized Naming for Any Function

Proposal: SE- 

Author(s): Doug Gregor 
Status: Awaiting Review
Review manager: TBD
 
Introduction

Swift includes support for first-class functions, such that any function (or 
method) can be placed into a value of function type. However, it is not 
possible to specifically name every function that is part of a Swift 
program---one cannot provide the argument labels when naming a function, nor 
are property and subscript getters and setters referenceable. This proposal 
introduces a general syntax that allows one to name anything that is a function 
within Swift in an extensible manner.

Swift-evolution thread: Michael Henson started a thread about the getter/setter 
issue here 
,
 continued here 
.
 See the Alternatives considered 

 section for commentary on that discussion.

 
Motivation

It's fairly common in Swift for multiple functions or methods to have the same 
"base name", but be distinguished by parameter labels. For example, UIView has 
three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different 
methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot 
provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview// ok: uses 
insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, otherView)
}
which is painfully tedious. A similar workaround is required to produce a 
function value for a getter of a property, e.g.,

extension UIButton {
  var currentTitle: String? { ... }
}

var fn: () -> String? = { () in
  return button.currentTitle
}
One additional bit of motivation: Swift should probably get some way to ask for 
the Objective-C selector for a given method (rather than writing a string 
literal). The argument to such an operation would likely be a reference to a 
method, which would benefit from being able to name any method, including 
getters and setters.

 
Proposed
 solution

Swift currently has a back-tick escaping syntax that lets one use keywords for 
names, which would otherwise fail to parse. For example,

func `try`() -> Bool { ... }
declares a function named try, even though try is a keyword. I propose to 
extend the back-tick syntax to allow compound Swift names (e.g., 
insertSubview(_:aboveSubview:)) and references to the accessors of properties 
(e.g., the getter for currentTitle). Specifically,

Compound names can be written entirely within the back-ticks, e.g.,

let fn = someView.`insertSubview(_:at:)`
let fn1 = someView.`insertSubview(_:aboveSubview:)`
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.`init(type:)`
Getters and setters can be written using dotted syntax within the back-ticks:

let specificTitle = button.`currentTitle.get` // has type () -> String?
let otherTitle = UIButton.`currentTitle.get`  // has type (UIButton) -> () -> 
String?
let setTintColor = button.`tintColor.set` // has type (UIColor!) -> ()
The same syntax works with 

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Chris Lattner via swift-evolution]

On Dec 25, 2015, at 12:04 PM, Matthew Johnson  wrote:
>>> Discussion on a couple of topics continues inline below as well.
>> 
>> Great, comments below:
> 
> Thanks for continuing the discussion.  I have updated the proposal to reflect 
> the core functionality and moved everything else to the future enhancements 
> section.  I think this draft is ready or nearly ready for a PR.
> 
> Here is a link to the current draft: 
> https://github.com/anandabits/swift-evolution/edit/flexible-memberwise-initialization/proposals/-flexible-memberwise-initialization.md
>  
> 
> 
> Here is a link to the commit diff: 
> https://github.com/anandabits/swift-evolution/commit/f15360d2e201709640f9137d86a8b705a07b5466?short_path=f5ec377#diff-f5ec377f4782587684c5732547456b70
>  
> 
Thanks again for pushing this forward, this is looking great.

>> It is also annoying that writing it as a static property would force you to 
>> write something like “X.a" instead of just “a”.
> 
> I agree with this.  I can accept an argument that this provides enough value 
> to avoid changing the language.
> 
> That said, I do think default values for let properties are higher value.  If 
> I had to pick one it would be default values and I would consider it to be 
> worthy of a breaking change in the language.  But It would be great if we can 
> find a way to support both.

I understand your desire, but this really is something we’ll have to discuss 
carefully.  Changing Swift soft that “let x = 42” doesn’t necessarily mean that 
x is 42 is a pretty deep semantic change, which will be surprising for many 
people (as was noted by others on this thread).  I agree that it would be great 
to get more flexible initialization for lets, but keep in mind that you can 
already do this long-hand if you want.

>> This I still have a concern with, in two ways:
>> 
>> 1) This still has tight coupling between the base and derived class.  
>> Properties in a based class are not knowable by a derived class in general 
>> (e.g. across module boundaries) and this directly runs afoul of our 
>> resilience plans.  Specifically, across module boundaries, properties can 
>> change from stored to computed (or back) without breaking clients.
>> 
>> 2) You’re introducing another unnecessary feature "super.init(…)” which will 
>> have to be independently justified. 
>> 
> 
> I will continue thinking about how this might be solved and also about other 
> cases where such a forwarding feature might be useful.  

Sounds good.  This is definitely an interesting area to investigate, but I 
don't want the general goodness of your base memberwise init proposal to have 
to wait :-)

>> Other comments:
>> 
>> In "Impact on existing code”, given your proposal, I think that we should 
>> keep the implicit memberwise initializer on classes, start generating it for 
>> root classes, and generate it for derived classes whose parent has a DI with 
>> no arguments (e.g. subclasses of NSObject).  We should keep the current 
>> behavior where it is generated with internal behavior, and it is surpressed 
>> if *any* initializers are defined inside of the type.
> 
> I’ll update that section to reflect these comments.  
> 
> One question I have is what the implicit memberwise initializer should do in 
> the case of private members.  If we make it follow the rules of this proposal 
> we would break existing structs with private members that are currently 
> receiving the implicit memberwise initializer.  
> 
> I think this would be a good breaking change for both consistency with this 
> proposal and because implicitly exposing private members via the initializer 
> was a questionable choice.  A mechanical migration could generate code to add 
> an explicit implementation of the previously implicit initializer that 
> doesn’t qualify under the rules of the new proposal.  How do you feel about 
> this?

I don’t have a strong opinion about this, and I can see reasonable arguments on 
either side.  Breaking source compatibility in this case isn’t a show-stopper, 
since this will roll out in Swift 3.

Here are the pros and cons as I see them with disallow-ing more-private fields 
to be published through less-private memberwise inits:

Neutral: Either approach is fine for “CGRect” like types that are really just 
public bags of public fields.
Pro: Makes logical sense at first blush.  Memberwise inits publishing private 
state would be odd/surprising.
Pro: Safer default, in that you don’t accidentally publish stuff you don’t want 
through a memberwise init.
Con: This puts tension between access control for stored properties and 
memberwise inits.  You have to choose between narrower access control or 
getting 

[swift-evolution] Beef up Imports

[Developer via swift-evolution]

I opened a radar a while ago about improving the import syntax in Swift and 
haven’t received much of a response, so I’ll try to expand on my thoughts in 
there here.

I’ve always been in love with the way Agda does Modules and imports.  The 
syntax is wonderfully natural, and the features it provides are surprisingly 
useful given their simplicity.  Because Swift forbids the redeclaration of 
names between structs, enums, classes, and typealiases, I don’t believe that 
the existing qualified import syntax is needed.  Therefore, I propose the 
introduction of 3 agda-esque operations for imports to replace the usual 
`import {func|typealias|struct|class|enum|etc.}` syntax:

• import Foo using (bar, Baz, qux, corge, …)
• import Foo hiding (bar, baz, qux, corge, …)
• import Foo renaming (grault to garply, waldo to fred, …)

The first of these is used to introduce a limited set of identifiers into 
scope, the second to import all but the given identifiers, and the third to 
rename identifiers at the module level.  Again, it should be obvious by 
uniqueness of identifiers what each one is referencing, so qualification of 
each identifier is unnecessary.  If more context is needed, or more 
granularity, a Haskell-esque 

import Foo {using|hiding|renaming} (Baz(..) [to Graft(..)])

could be in order for structs, classes, and enums, but I don’t anticipate it 
will be of much use because individual members are already qualified by their 
containing structure or instance variable anyway. 

What do you think?

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

Re: [swift-evolution] Proposal for Package Manager Testing Infrastruture

[Drew Crawford via swift-evolution]

I'm wondering what the next steps for this proposal are.

I see Max's comment from the 16th 
 
advising to pull back discussion to the list, but I haven't seen any further 
discussion in the past 10 days.  Does someone feel that there are outstanding 
problems to address?  Even if there is some further discussion we need to have, 
IMO it would be appropriate to have that discussion in the context of a 
swift-evolution review.

I personally back the proposal essentially in its entirety.  I think it is 
vague on some points we will want to take up as separate proposals, but I don't 
think they are worth holding up the ability to test packages at all, which is 
the present situation.

I am not familiar with what exactly the criteria is for that PR to be accepted 
into swift-evolution and begin a review, which IIRC is the next stage in the 
process.  I do notice that it is the second oldest of the 12 open PRs in the 
queue.




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

Re: [swift-evolution] Immutable Structures

[Brent Royal-Gordon via swift-evolution]

> > "In a regular method, `self` is a regular (constant) parameter, but in a 
> > `mutating` method, `self` is `inout` so that it can be mutated and those 
> > mutations will reach the caller's copy of the instance. There's no need for 
> > an `inout` `self` on reference types, because the mutations are performed 
> > on the shared instance which both the caller and callee have a reference 
> > to, so `mutating` only really makes sense for value types."
> 
> But the `mutating` keyword isn't really needed to make `self` work this way 
> for structures. It's actually not strictly needed at all. Another thing the 
> `mutating` keyword "allows" is for the method to be able to reassign 
> properties. I was advocating that `mutating` had only that meaning in order 
> to be more consistent. Then it would be equally useful for classes to make 
> APIs more clear with respect to mutation.

I don't think you quite understand what I'm saying. You can mutate properties 
in a `mutating` method *because* `self` is an `inout` parameter in a mutating 
method. That's how mutating the properties is implemented.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

[Joe Groff via swift-evolution]

> On Dec 25, 2015, at 12:29 PM, Árpád Goretity  wrote:
> 
> > ObjC bridging means that an array might really be an opaque NSArray 
> > subclass we can't get a buffer from
> 
> Ah, I totally forgot about that. (not trying to be a pain, but NSArray could 
> as well expose its buffer… if and only if the subclass in use doesn't do the 
> usual circular buffer optimization. But then again, I see why this is 
> difficult, so let's just leave it there.)

The default NS/CFArray implementation does provide internal interfaces to get 
at its buffer which we take advantage of. In general, though, an NSArray 
subclass doesn't need to offer anything more than `objectAtIndex:` and `count`, 
so we have to be able to deal with a potentially fully opaque interface.

> > By fencing the pointer's validity to a particular scope we can also keep 
> > array value semantics safe
> 
> Sure thing. So does this then mean that the kind of "unsafe/real address-of" 
> operation can't be generally realized?


It might be possible, but the interactions between pointer-level and high-level 
accesses would get pretty complex. After a certain point of pointer and 
lifetime complexity, the high level semantics are just getting in your way IMO, 
and malloc/free start to be more appealing.

-Joe

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

Re: [swift-evolution] Proposal - Allow properties in Extensions

[Matthew Johnson via swift-evolution]

I’ve been giving this further thought today.

Thinking about extensions that require non-default initialization led to 
thinking about protocols that require non-default initialization.  

I can see significant value in allowing protocols to have stored properties 
that require non-default initialization.  This would effectively get us all the 
way to very robust, encapsulated mixin functionality.  It would enable design 
techniques that would not otherwise be possible.  

Once we have a concept of “partial initialization” of self in the language 
supporting it for same-module extensions starts to make more sense to me as a 
natural way to build on that.

As with extensions requiring non-default initialization, conformance of such 
protocols would only be supported in the module declaring the type itself, and 
perhaps only in the declaration itself. This being the case, storage could even 
be inline. 

It might look something like this:

protocol P {
  // requirements of the protocol
  // ...

  stored let s: String
  protocol init(s: String) {
// protocol cannot use self to reference any of its instance requirements 
yet
// as self is not fully initialized
self.s = s
  }
}

class C: P {
  let i: Int
  init() {
i = 42
P.init(“hello”)
  }
}

A few things to note.  

The protocol would need a way to indicate its initializer is a partial 
initializer that initializes the protocol’s storage rather than being an 
initializer requirement.  It would also need a way to indicate that specific 
properties are stored directly rather than specifying requirements.  I used 
`stored` and `protocol init` for this purpose in the above example but the 
syntax could look different in a final solution.  

The protocol may also wish to apply access control to its stored members as 
well.  

If we allow both the protocol and the type itself to have distinct properties 
with the same name they would need to have distinct storage.  The protocol’s 
stored property could not be treated as an overridable requirement of the 
protocol.  When accessing the type via its protocol interface the protocol’s 
storage would be used.  When accessing the type directly its storage would be 
used.  

I’m sure there are plenty more details to consider.  

Given its potential to enable robust mixins, I am really starting to warm to 
the idea of partial-self initialization.

Matthew

> On Dec 26, 2015, at 9:10 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 25, 2015, at 12:02 AM, John McCall > > wrote:
>> 
>>> On Dec 24, 2015, at 12:10 PM, Matthew Johnson >> > wrote:
 On Dec 24, 2015, at 2:05 PM, John McCall >>> > wrote:
 
> On Dec 24, 2015, at 11:48 AM, Matthew Johnson  > wrote:
>> On Dec 24, 2015, at 1:31 PM, John McCall > > wrote:
>> 
>> 
>>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson >> > wrote:
>>> 
>>> 
> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Dec 23, 2015, at 7:05 AM, Paul Cantrell  > wrote:
>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> when you stuff a lot of functionality into a single class in most OO 
>> languages, there’s no real way to enforce its division into 
>> subsystems, because every method has direct access to every property 
>> and every other method.  In contrast, in Swift you can divide that 
>> class into distinct components with their own interface, state, and 
>> invariants, essentially making each component as good as its own 
>> type as far as encapsulation goes.
> 
> Can you elaborate on this, John? Extensions and protocols in Swift 
> today still don’t solve the problem that shared _private_ class state 
> has to be centralized. Or were you speaking as if this “properties in 
> extensions” proposal were already implemented?
 
 Yes, that’s right.  I’m explaining why I think it makes sense to limit 
 stored instance properties in extensions to class types: especially 
 with some solution for private initialization of extensions, they 
 enable intra-class encapsulation in a way that matters for classes and 
 not really for other types.
>>> 
>>> How would private initialization of extensions work?
>> 
>> Just spit-balling, but something like:
>> 
>> class A {
>> init(numbers: [Int]) {
>>   // Definitive initialization requires initialization of all the 
>> extensions
>>   // in the module that declare partial inits before the call to 
>> super.

Re: [swift-evolution] Adding custom attributes

[Radosław Smogura via swift-evolution]

> On 26 Dec 2015, at 19:57, JOSE MARIA GOMEZ CAMA  wrote:
> 
> Dear all,
> 
> Let me answer inlined.
> 
>> El 26/12/2015, a las 19:15, Radosław Smogura via swift-evolution 
>>  escribió:
>> 
>> Hi Dimitir,
>> 
>> Thanks for your questions, as you pointed me to deeper considerations and 
>> better description of idea.
>> 
>>> On 26 Dec 2015, at 16:20, Dmitri Gribenko  wrote:
>>> 
>>> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura  
>>> wrote:
 So,
 
 What do you think about syntax like this:
 
 // Declaration
 @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into 
 binary
 @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
 @attribute JSONProperty {
 var name:String!;
 var serializable:Bool? = true;
 var deserializable:Bool? = true;
 }
>>> 
>>> Is this a new declaration kind?  Do you think we could make it work
>>> with existing language constructs instead, like structs?  Any
>>> downsides to that?
>> It’s really good concern and I have to describe attribute concept in more 
>> details. The _implementation_ of attributes would and should use existing 
>> constructs like structs or classes - I prefer classes as it will allow 
>> attributes to subclass some common class (Attribute?), so in future new 
>> functionality can be added.
>> 
>> Let’s consider attributes, and marking struct with @Attrbute.
>> 
>> On runtime attributes will be passed as references or value objects (just to 
>> keep contract programming) and assignment to attribute properties should be 
>> prohibited:
>> - if attribute is bound to type, than attribute would be nothing more than 
>> extension of static context of that type,
>> - it’s error prone for developers, as someone could change i.e. JSON 
>> property name.
>> 
>> Attributes are metadata, and do not require methods (however methods could 
>> be interesting and innovative addition). So attribute’s properties should be 
>> declared with let, instead of var, to prevent modification of those, but 
>> from other hand we would like to set default values for some properties, I 
>> just think that declaration like this would be confusing:
>> @Attribute
>> struct JSONProperty {
>> /* … */
>> let deserializable:Bool? = true;
>> }
>> 
>> Additionally having attributes as a new construct will give us more 
>> flexibility on changing syntax and adding new features in future.
>> 
>> I think this implies that attribute can’t be considered as struct (on 
>> language level), and should be treated as new language construct.
> 
> I do not agree that attributes should only provide metadata. I think they 
> shall also provide means, like in Java or Python, to modify the behavior in 
> runtime. For this, mirroring would be needed.
My bad, I think I unnesessary  used a word ‘metadata’ word. It may be confusing.

You are right it is something we would like to achieve, but attribute alone is 
disconnected from mean. Mean (with some exceptions), similar like in Java, 
should be defined by library / container which inspects annotations on given 
object. 

> 
 // Usage
 @JSONProperty(name=“id”)
 var id:Int;
 
 
 Attributes should be module aware (actual attributes should be redefined 
 as Swift attribute, for beginning still can be hardcoded).
>>> 
>>> Sorry, I'm not sure what this means.
>> Attributes should be in module. So modules can define attributes with same 
>> name. Right now attributes are global.
>>> 
 The attribute’s name have to be unique in module. It’s compile time error 
 if attribute, class, enum, struct, etc has same name.
 
 Attribute’s properties are read only and can’t be assigned - so during 
 reflection no-one would change ‘shared’ values.
>>> 
>>> I think using structs and requiring that attributes are value types
>>> would solve both issues.
>> I think attributes should be treated as new language construct, regardless 
>> how those will be implemented on runtime - it can be struct or class.
> 
> I do not see why it should be a new construct, in Java it is, but in case of 
> Python it is not. Another option would be to define the attribute @attribute 
> that would identify a class or a struct as an attribute.
> 
 Attribute’s properties can only support basic types: primitives, strings, 
 types, and other attributes (optional).
>>> 
>>> Well, there is no such thing as "basic types" in Swift.  Strings,
>>> integers etc. are defined in the standard library and the compiler
>>> does not know anything special about them.
>> By basic type I meant a types which can be serialised to format which will 
>> not change in future. Numbers, strings, type names, arrays of those can be 
>> stored in binaries without risks of backward incompatibility, objects and 
>> structs are more fragile. I think next answer will clarify more.
> 
> I think this is always the case when you have a compiled language, you always 
> store information as a binary when you have a libr

Re: [swift-evolution] swift-evolution Digest, Vol 1, Issue 237

[Akiva Leffert via swift-evolution]

I started off a thread about this a while back: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001455.html
 


Based on the feedback I got, it seemed like the design for a serious custom 
annotation system should wait until work starts on a macro system so that they 
can be designed to complement each other. IMO, neither the java nor python 
versions feel right for swift and we can do a lot better than just copying them 
so it’s worth spending the time to get it right.

Additionally, the property behaviors proposal currently on the table would 
cover some of the use cases for annotations, depending on where it lands. It 
seems plausible that we can make all these features work together in a nice 
way. 

Maybe it’s worth setting up a wiki page or something for use cases of 
annotations to help inform a future design as well as the design of related 
features?

-Akiva Leffert

> 
> Message: 18
> Date: Sat, 26 Dec 2015 10:03:35 +
> From: JOSE MARIA GOMEZ CAMA 
> To: "swift-evolution@swift.org" 
> Subject: [swift-evolution] Support for custom attributes
> Message-ID: <331f173e-0a78-44cc-a1e8-e30538431...@ub.edu>
> Content-Type: text/plain; charset=utf-8
> 
> Dear all,
> 
> I am quite new to Swift, though I have made some small checks within Xcode, 
> so I could have missed some feature in swift that provides a functionality 
> similar to the want I am proposing.
> 
> I have been using my own annotations in Java or decorators in Python, and I 
> would like to have an equivalent functionality in Swift. As far as I have 
> seen, there are attributes that can provide a similar solution, but AFAIK you 
> cannot create new ones. Would it be possible to add this feature in Swift.
> 
>Thanks in advance,
> 
>Jose M.
> 
> 
> 
> Aquest correu electrònic i els annexos poden contenir informació confidencial 
> o protegida legalment i està adreçat exclusivament a la persona o entitat 
> destinatària. Si no sou el destinatari final o la persona encarregada de 
> rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, 
> distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si heu rebut aquest 
> correu electrònic per error, us preguem que n’informeu al remitent i que 
> elimineu del sistema el missatge i el material annex que pugui contenir. 
> Gràcies per la vostra col·laboració.
> 
> Este correo electrónico y sus anexos pueden contener información confidencial 
> o legalmente protegida y está exclusivamente dirigido a la persona o entidad 
> destinataria. Si usted no es el destinatario final o la persona encargada de 
> recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo, 
> copiarlo ni a revelar su contenido. Si ha recibido este mensaje electrónico 
> por error, le rogamos que informe al remitente y elimine del sistema el 
> mensaje y el material anexo que pueda contener. Gracias por su colaboración.
> 
> This email message and any documents attached to it may contain confidential 
> or legally protected material and are intended solely for the use of the 
> individual or organization to whom they are addressed. We remind you that if 
> you are not the intended recipient of this email message or the person 
> responsible for processing it, then you are not authorized to read, save, 
> modify, send, copy or disclose any of its contents. If you have received this 
> email message by mistake, we kindly ask you to inform the sender of this and 
> to eliminate both the message and any attachments it carries from your 
> account. Thank you for your collaboration.
> 

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

Re: [swift-evolution] Adding custom attributes

[Félix Cloutier via swift-evolution]

Consider reading the Property Behaviors 

 proposal, as attributes overlap with it. (Warning: lng thread)

Félix

> Le 26 déc. 2015 à 13:57:04, JOSE MARIA GOMEZ CAMA via swift-evolution 
>  a écrit :
> 
> Dear all,
> 
> Let me answer inlined.
> 
>> El 26/12/2015, a las 19:15, Radosław Smogura via swift-evolution 
>>  escribió:
>> 
>> Hi Dimitir,
>> 
>> Thanks for your questions, as you pointed me to deeper considerations and 
>> better description of idea.
>> 
>>> On 26 Dec 2015, at 16:20, Dmitri Gribenko  wrote:
>>> 
>>> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura  
>>> wrote:
 So,
 
 What do you think about syntax like this:
 
 // Declaration
 @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into 
 binary
 @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
 @attribute JSONProperty {
 var name:String!;
 var serializable:Bool? = true;
 var deserializable:Bool? = true;
 }
>>> 
>>> Is this a new declaration kind?  Do you think we could make it work
>>> with existing language constructs instead, like structs?  Any
>>> downsides to that?
>> It’s really good concern and I have to describe attribute concept in more 
>> details. The _implementation_ of attributes would and should use existing 
>> constructs like structs or classes - I prefer classes as it will allow 
>> attributes to subclass some common class (Attribute?), so in future new 
>> functionality can be added.
>> 
>> Let’s consider attributes, and marking struct with @Attrbute.
>> 
>> On runtime attributes will be passed as references or value objects (just to 
>> keep contract programming) and assignment to attribute properties should be 
>> prohibited:
>> - if attribute is bound to type, than attribute would be nothing more than 
>> extension of static context of that type,
>> - it’s error prone for developers, as someone could change i.e. JSON 
>> property name.
>> 
>> Attributes are metadata, and do not require methods (however methods could 
>> be interesting and innovative addition). So attribute’s properties should be 
>> declared with let, instead of var, to prevent modification of those, but 
>> from other hand we would like to set default values for some properties, I 
>> just think that declaration like this would be confusing:
>> @Attribute
>> struct JSONProperty {
>> /* … */
>> let deserializable:Bool? = true;
>> }
>> 
>> Additionally having attributes as a new construct will give us more 
>> flexibility on changing syntax and adding new features in future.
>> 
>> I think this implies that attribute can’t be considered as struct (on 
>> language level), and should be treated as new language construct.
> 
> I do not agree that attributes should only provide metadata. I think they 
> shall also provide means, like in Java or Python, to modify the behavior in 
> runtime. For this, mirroring would be needed.
> 
 // Usage
 @JSONProperty(name=“id”)
 var id:Int;
 
 
 Attributes should be module aware (actual attributes should be redefined 
 as Swift attribute, for beginning still can be hardcoded).
>>> 
>>> Sorry, I'm not sure what this means.
>> Attributes should be in module. So modules can define attributes with same 
>> name. Right now attributes are global.
>>> 
 The attribute’s name have to be unique in module. It’s compile time error 
 if attribute, class, enum, struct, etc has same name.
 
 Attribute’s properties are read only and can’t be assigned - so during 
 reflection no-one would change ‘shared’ values.
>>> 
>>> I think using structs and requiring that attributes are value types
>>> would solve both issues.
>> I think attributes should be treated as new language construct, regardless 
>> how those will be implemented on runtime - it can be struct or class.
> 
> I do not see why it should be a new construct, in Java it is, but in case of 
> Python it is not. Another option would be to define the attribute @attribute 
> that would identify a class or a struct as an attribute.
> 
 Attribute’s properties can only support basic types: primitives, strings, 
 types, and other attributes (optional).
>>> 
>>> Well, there is no such thing as "basic types" in Swift.  Strings,
>>> integers etc. are defined in the standard library and the compiler
>>> does not know anything special about them.
>> By basic type I meant a types which can be serialised to format which will 
>> not change in future. Numbers, strings, type names, arrays of those can be 
>> stored in binaries without risks of backward incompatibility, objects and 
>> structs are more fragile. I think next answer will clarify more.
> 
> I think this is always the case when you have a compiled language, you always 
> store information as a binary when you have a library.
> 
 When declaring attributes, properties can be set to constant values 
 (stati

Re: [swift-evolution] Adding custom attributes

[JOSE MARIA GOMEZ CAMA via swift-evolution]

Dear all,

Let me answer inlined.

> El 26/12/2015, a las 19:15, Radosław Smogura via swift-evolution 
>  escribió:
>
> Hi Dimitir,
>
> Thanks for your questions, as you pointed me to deeper considerations and 
> better description of idea.
>
>> On 26 Dec 2015, at 16:20, Dmitri Gribenko  wrote:
>>
>> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura  
>> wrote:
>>> So,
>>>
>>> What do you think about syntax like this:
>>>
>>> // Declaration
>>> @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into binary
>>> @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
>>> @attribute JSONProperty {
>>> var name:String!;
>>> var serializable:Bool? = true;
>>> var deserializable:Bool? = true;
>>> }
>>
>> Is this a new declaration kind?  Do you think we could make it work
>> with existing language constructs instead, like structs?  Any
>> downsides to that?
> It’s really good concern and I have to describe attribute concept in more 
> details. The _implementation_ of attributes would and should use existing 
> constructs like structs or classes - I prefer classes as it will allow 
> attributes to subclass some common class (Attribute?), so in future new 
> functionality can be added.
>
> Let’s consider attributes, and marking struct with @Attrbute.
>
> On runtime attributes will be passed as references or value objects (just to 
> keep contract programming) and assignment to attribute properties should be 
> prohibited:
> - if attribute is bound to type, than attribute would be nothing more than 
> extension of static context of that type,
> - it’s error prone for developers, as someone could change i.e. JSON property 
> name.
>
> Attributes are metadata, and do not require methods (however methods could be 
> interesting and innovative addition). So attribute’s properties should be 
> declared with let, instead of var, to prevent modification of those, but from 
> other hand we would like to set default values for some properties, I just 
> think that declaration like this would be confusing:
> @Attribute
> struct JSONProperty {
> /* … */
> let deserializable:Bool? = true;
> }
>
> Additionally having attributes as a new construct will give us more 
> flexibility on changing syntax and adding new features in future.
>
> I think this implies that attribute can’t be considered as struct (on 
> language level), and should be treated as new language construct.

I do not agree that attributes should only provide metadata. I think they shall 
also provide means, like in Java or Python, to modify the behavior in runtime. 
For this, mirroring would be needed.

>>> // Usage
>>> @JSONProperty(name=“id”)
>>> var id:Int;
>>>
>>>
>>> Attributes should be module aware (actual attributes should be redefined as 
>>> Swift attribute, for beginning still can be hardcoded).
>>
>> Sorry, I'm not sure what this means.
> Attributes should be in module. So modules can define attributes with same 
> name. Right now attributes are global.
>>
>>> The attribute’s name have to be unique in module. It’s compile time error 
>>> if attribute, class, enum, struct, etc has same name.
>>>
>>> Attribute’s properties are read only and can’t be assigned - so during 
>>> reflection no-one would change ‘shared’ values.
>>
>> I think using structs and requiring that attributes are value types
>> would solve both issues.
> I think attributes should be treated as new language construct, regardless 
> how those will be implemented on runtime - it can be struct or class.

I do not see why it should be a new construct, in Java it is, but in case of 
Python it is not. Another option would be to define the attribute @attribute 
that would identify a class or a struct as an attribute.

>>> Attribute’s properties can only support basic types: primitives, strings, 
>>> types, and other attributes (optional).
>>
>> Well, there is no such thing as "basic types" in Swift.  Strings,
>> integers etc. are defined in the standard library and the compiler
>> does not know anything special about them.
> By basic type I meant a types which can be serialised to format which will 
> not change in future. Numbers, strings, type names, arrays of those can be 
> stored in binaries without risks of backward incompatibility, objects and 
> structs are more fragile. I think next answer will clarify more.

I think this is always the case when you have a compiled language, you always 
store information as a binary when you have a library.

>>> When declaring attributes, properties can be set to constant values (static 
>>> let) or enum values, however the final value is stored in binary, not a 
>>> reference to it.
>>
>> Again, given that strings are defined in the standard library, and
>> that the language does not have a notion of a constant expression, I'm
>> not sure how this would work.  I'm not saying it can't, I'm just
>> saying you need to introduce a lot of new language concepts and
>> compiler machinery.
> It’s another good question. By const I mean vir

Re: [swift-evolution] Adding custom attributes

[Radosław Smogura via swift-evolution]

Hi Dimitir,

Thanks for your questions, as you pointed me to deeper considerations and 
better description of idea.

> On 26 Dec 2015, at 16:20, Dmitri Gribenko  wrote:
> 
> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura  wrote:
>> So,
>> 
>> What do you think about syntax like this:
>> 
>> // Declaration
>> @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into binary
>> @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
>> @attribute JSONProperty {
>> var name:String!;
>> var serializable:Bool? = true;
>> var deserializable:Bool? = true;
>> }
> 
> Is this a new declaration kind?  Do you think we could make it work
> with existing language constructs instead, like structs?  Any
> downsides to that?
It’s really good concern and I have to describe attribute concept in more 
details. The _implementation_ of attributes would and should use existing 
constructs like structs or classes - I prefer classes as it will allow 
attributes to subclass some common class (Attribute?), so in future new 
functionality can be added.

Let’s consider attributes, and marking struct with @Attrbute.

On runtime attributes will be passed as references or value objects (just to 
keep contract programming) and assignment to attribute properties should be 
prohibited:
- if attribute is bound to type, than attribute would be nothing more than 
extension of static context of that type,
- it’s error prone for developers, as someone could change i.e. JSON property 
name.

Attributes are metadata, and do not require methods (however methods could be 
interesting and innovative addition). So attribute’s properties should be 
declared with let, instead of var, to prevent modification of those, but from 
other hand we would like to set default values for some properties, I just 
think that declaration like this would be confusing:
@Attribute
struct JSONProperty {
/* … */
let deserializable:Bool? = true;
}

Additionally having attributes as a new construct will give us more flexibility 
on changing syntax and adding new features in future.

I think this implies that attribute can’t be considered as struct (on language 
level), and should be treated as new language construct.

>> // Usage
>> @JSONProperty(name=“id”)
>> var id:Int;
>> 
>> 
>> Attributes should be module aware (actual attributes should be redefined as 
>> Swift attribute, for beginning still can be hardcoded).
> 
> Sorry, I'm not sure what this means.
Attributes should be in module. So modules can define attributes with same 
name. Right now attributes are global.
> 
>> The attribute’s name have to be unique in module. It’s compile time error if 
>> attribute, class, enum, struct, etc has same name.
>> 
>> Attribute’s properties are read only and can’t be assigned - so during 
>> reflection no-one would change ‘shared’ values.
> 
> I think using structs and requiring that attributes are value types
> would solve both issues.
I think attributes should be treated as new language construct, regardless how 
those will be implemented on runtime - it can be struct or class.

>> Attribute’s properties can only support basic types: primitives, strings, 
>> types, and other attributes (optional).
> 
> Well, there is no such thing as "basic types" in Swift.  Strings,
> integers etc. are defined in the standard library and the compiler
> does not know anything special about them.
By basic type I meant a types which can be serialised to format which will not 
change in future. Numbers, strings, type names, arrays of those can be stored 
in binaries without risks of backward incompatibility, objects and structs are 
more fragile. I think next answer will clarify more.

>> When declaring attributes, properties can be set to constant values (static 
>> let) or enum values, however the final value is stored in binary, not a 
>> reference to it.
> 
> Again, given that strings are defined in the standard library, and
> that the language does not have a notion of a constant expression, I'm
> not sure how this would work.  I'm not saying it can't, I'm just
> saying you need to introduce a lot of new language concepts and
> compiler machinery.
It’s another good question. By const I mean virtual concept of static let 
declaration. My motivation is to keep attributes as static metadata.

Let’s consider three levels of attributes:
- source - those attributes are present only in source file and are not put in 
binary, such attributes can be used to mark pieces of code for external tools 
like visual UI designers, UMLs, etc
- compile - those attributes are present in output binary, but have not meaning 
on runtime - ie. @Deprecated,
- runtime - those attributes are present on runtime, and can be inspected by 
libraries to affect execution, ie.: @JSONProperty, @NSManaged

My other concern is related to attribute storage (let’s skip implementation of 
this). Suppose you want to centralise some values, ie. messages with following 
pice of code
CommonMessages {
static va

Re: [swift-evolution] Immutable Structures

[Austin Zheng via swift-evolution]

Given that the Swift team has already said they aren't going to change the 
programming model, I don't think further conversation belongs on 
swift-evolution, to be honest.

Austin

> On Dec 26, 2015, at 8:50 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> If you're serious about your proposal, you need to come up with a realistic 
> plan for phasing out the current struct semantics for everyone, in every use 
> case that they have.
> 
> Félix
> 
>> Le 26 déc. 2015 à 11:14:44, Lino Rosa via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> 
>> > "1) Its not true. Its just about the reassignment. But for value-types in 
>> > automatic the process of copy-change and assign."
>> 
>> I understand that, but semantically it sure looks like it's true. It's an 
>> implementation detail, all about the copy-on-write optimization right? Why 
>> should the developer have to know about that?
>> 
>> > "2) because only value types need this keyword"
>> > "3) what's the problem here?"
>> 
>> Consistency. Makes the language harder to explain. To me the `mutating` 
>> keyword should either be used in classes as well or not used at all. Both 
>> would simplify things. But this is running off-topic from the original post 
>> though.
>> 
>> > "Can you elaborate this? Does not appear a real world problem."
>> 
>> Not a specific example, but every line like `something.a = "anotherValue"` 
>> might or might not be relying on value semantics. After refactoring, the 
>> developer would have no choice but to read every line with `something` and 
>> judge whether value semantics was assumed or it was irrelevant. Really error 
>> prone. Any mistake would result in unintended reference sharing, race 
>> conditions etc. The actual bug might surface far from the originating issue.
>> 
>> > "hu?  Just check if the type is a struct or a enum! So will be a value 
>> > type. Whats the problem here?"
>> 
>> Of course, but you'd have to pause reading and jump to the definition each 
>> time. And keep two mental models when structures and classes are used 
>> together.
>> 
>> > "No, the whole point of structs are not to be used in small and simple 
>> > cases, not on Swift, in swift um Swift are first class citizen and can be 
>> > use for complex data structure, like Array and Strings. You can make a 
>> > private shared buffer behind the scenes."
>> 
>> It does certainly seem to be this way in practice. It was the impression I 
>> got from Swift's official docs: "The structure’s primary purpose is to 
>> encapsulate a few relatively simple data values.". But now I realize it 
>> talks about other possible use cases.
>> 
>> > "Try this one: https://developer.apple.com/videos/play/wwdc2015-408/ 
>> >  ( 
>> > Protocol-Oriented Programming in Swift )"
>> 
>> I enjoyed this one, but it's about inheritance vs. protocols. He changes 
>> classes to structures because he thinks it fits the model but he could have 
>> kept classes and still proved his point that protocols are more powerful and 
>> flexible. 
>> 
>> I called my attention though, at around 25:20m he shows 
>> `diagram.elements.append(diagram)` and says: "Now, it took me a second to 
>> realize why Drawing wasn't going into an infinite recursion at this point". 
>> That's kind of my point, these little surprises sprinkled around the code.
>> 
>> Brent Royal-Gordon:
>> 
>> > "In a regular method, `self` is a regular (constant) parameter, but in a 
>> > `mutating` method, `self` is `inout` so that it can be mutated and those 
>> > mutations will reach the caller's copy of the instance. There's no need 
>> > for an `inout` `self` on reference types, because the mutations are 
>> > performed on the shared instance which both the caller and callee have a 
>> > reference to, so `mutating` only really makes sense for value types."
>> 
>> But the `mutating` keyword isn't really needed to make `self` work this way 
>> for structures. It's actually not strictly needed at all. Another thing the 
>> `mutating` keyword "allows" is for the method to be able to reassign 
>> properties. I was advocating that `mutating` had only that meaning in order 
>> to be more consistent. Then it would be equally useful for classes to make 
>> APIs more clear with respect to mutation.
>> 
>> 
>> On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon > > wrote:
>> > However I could probably still agree with you if mutating was also used in 
>> > classes. What's the point of having it only on structures?
>> 
>> In a regular method, `self` is a regular (constant) parameter, but in a 
>> `mutating` method, `self` is `inout` so that it can be mutated and those 
>> mutations will reach the caller's copy of the instance. There's no need for 
>> an `inout` `self` on reference types, because the mutations are performed on 
>> the shared instance which both the caller and callee have a reference to, so 
>> `mutating`

Re: [swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

[T.J. Usiyan via swift-evolution]

We've asked this a few times. Chris Lattner has said something about it
already.

"There are no short term plans.  Unless you’d consider rewriting all of
LLVM as part of the project (something that would be awesome, but that I
wouldn’t recommend :-), we’d need Swift to be able to import C++ APIs.  I’m
personally hopeful that we’ll be able to tackle at least some of that in
Swift 4, but we’ll see - no planning can be done for Swift 4 until Swift 3
starts to wind down." - Chris




On Fri, Dec 25, 2015 at 8:26 PM, Andrew Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> This may address many of the concerns, and perhaps lower the barriers to
> the community contributing:
>  How about instead of rewriting the entire compiler in Swift, we just
> rewrite the Swift -> SIL component?
>
> On Mon, Dec 21, 2015 at 10:54 PM, Jean-Daniel Dupas via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >
>> >
>> >> On Dec 19, 2015, at 7:32 PM, Amir Michail  wrote:
>> >>
>> >>
>> >>> On Dec 19, 2015, at 7:21 PM, Colin Barrett <
>> co...@springsandstruts.com> wrote:
>> >>>
>> >>> I’d recommend you read
>> http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done,
>> which has a number of rebuttals to what you’ve said below.
>> >>>
>> >>
>> >> That’s an interesting article but it doesn’t address the issue of
>> whether compiler code is more like normal programming than compiler
>> standard library code.
>> >
>> > Perhaps I don’t understand what you mean, but the article gives two
>> good reasons why compiler code is special. The first reason is that we
>> understand a lot about how to design a compiler, much more than we
>> understand about how to design other types of programs. The second follows:
>> >
>> >> [C]ompilers are an atypical class of program. In essence, a compiler
>> is a simple batch pipeline process. A program is read in and translated to
>> a tree; a series of tree transformations are applied; and eventually one of
>> those trees is saved out as some sort of binary data (e.g. machine code or
>> bytecode). Most of the intermediate tree transformations calculate a
>> relatively simple bit of information about the program and create a
>> slightly modified tree based on it. A few calculations crop up time and
>> time again, such as: maps from variables to scopes or types; and stacks to
>> determine closures. Significantly, and unlike most programs in the real
>> world, there is no interaction with users: the compiler knows all it needs
>> about the outside world from the moment it is called.
>> >
>> > Personally, I think the main reason not to rewrite the Swift compiler
>> is that it would be a distraction from improving the Swift language and
>> other associated tools.
>> >
>> > -Colin
>> >
>>
>> An other reason is that is make it harder to port to new platforms. You
>> would have to do all the dev using cross compilation from another platform
>> instead of just working on the target platform directly.
>>
>> Jean-Daniel
>>
>> ___
>> 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] Immutable Structures

[Félix Cloutier via swift-evolution]

If you're serious about your proposal, you need to come up with a realistic 
plan for phasing out the current struct semantics for everyone, in every use 
case that they have.

Félix

> Le 26 déc. 2015 à 11:14:44, Lino Rosa via swift-evolution 
>  a écrit :
> 
> 
> > "1) Its not true. Its just about the reassignment. But for value-types in 
> > automatic the process of copy-change and assign."
> 
> I understand that, but semantically it sure looks like it's true. It's an 
> implementation detail, all about the copy-on-write optimization right? Why 
> should the developer have to know about that?
> 
> > "2) because only value types need this keyword"
> > "3) what's the problem here?"
> 
> Consistency. Makes the language harder to explain. To me the `mutating` 
> keyword should either be used in classes as well or not used at all. Both 
> would simplify things. But this is running off-topic from the original post 
> though.
> 
> > "Can you elaborate this? Does not appear a real world problem."
> 
> Not a specific example, but every line like `something.a = "anotherValue"` 
> might or might not be relying on value semantics. After refactoring, the 
> developer would have no choice but to read every line with `something` and 
> judge whether value semantics was assumed or it was irrelevant. Really error 
> prone. Any mistake would result in unintended reference sharing, race 
> conditions etc. The actual bug might surface far from the originating issue.
> 
> > "hu?  Just check if the type is a struct or a enum! So will be a value 
> > type. Whats the problem here?"
> 
> Of course, but you'd have to pause reading and jump to the definition each 
> time. And keep two mental models when structures and classes are used 
> together.
> 
> > "No, the whole point of structs are not to be used in small and simple 
> > cases, not on Swift, in swift um Swift are first class citizen and can be 
> > use for complex data structure, like Array and Strings. You can make a 
> > private shared buffer behind the scenes."
> 
> It does certainly seem to be this way in practice. It was the impression I 
> got from Swift's official docs: "The structure’s primary purpose is to 
> encapsulate a few relatively simple data values.". But now I realize it talks 
> about other possible use cases.
> 
> > "Try this one: https://developer.apple.com/videos/play/wwdc2015-408/ 
> >  ( Protocol-Oriented 
> > Programming in Swift )"
> 
> I enjoyed this one, but it's about inheritance vs. protocols. He changes 
> classes to structures because he thinks it fits the model but he could have 
> kept classes and still proved his point that protocols are more powerful and 
> flexible. 
> 
> I called my attention though, at around 25:20m he shows 
> `diagram.elements.append(diagram)` and says: "Now, it took me a second to 
> realize why Drawing wasn't going into an infinite recursion at this point". 
> That's kind of my point, these little surprises sprinkled around the code.
> 
> Brent Royal-Gordon:
> 
> > "In a regular method, `self` is a regular (constant) parameter, but in a 
> > `mutating` method, `self` is `inout` so that it can be mutated and those 
> > mutations will reach the caller's copy of the instance. There's no need for 
> > an `inout` `self` on reference types, because the mutations are performed 
> > on the shared instance which both the caller and callee have a reference 
> > to, so `mutating` only really makes sense for value types."
> 
> But the `mutating` keyword isn't really needed to make `self` work this way 
> for structures. It's actually not strictly needed at all. Another thing the 
> `mutating` keyword "allows" is for the method to be able to reassign 
> properties. I was advocating that `mutating` had only that meaning in order 
> to be more consistent. Then it would be equally useful for classes to make 
> APIs more clear with respect to mutation.
> 
> 
> On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon  > wrote:
> > However I could probably still agree with you if mutating was also used in 
> > classes. What's the point of having it only on structures?
> 
> In a regular method, `self` is a regular (constant) parameter, but in a 
> `mutating` method, `self` is `inout` so that it can be mutated and those 
> mutations will reach the caller's copy of the instance. There's no need for 
> an `inout` `self` on reference types, because the mutations are performed on 
> the shared instance which both the caller and callee have a reference to, so 
> `mutating` only really makes sense for value types.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Immutable Structures

[Lino Rosa via swift-evolution]

> "1) Its not true. Its just about the reassignment. But for value-types in
automatic the process of copy-change and assign."

I understand that, but semantically it sure looks like it's true. It's an
implementation detail, all about the copy-on-write optimization right? Why
should the developer have to know about that?

> "2) because only value types need this keyword"
> "3) what's the problem here?"

Consistency. Makes the language harder to explain. To me the `mutating`
keyword should either be used in classes as well or not used at all. Both
would simplify things. But this is running off-topic from the original post
though.

> "Can you elaborate this? Does not appear a real world problem."

Not a specific example, but every line like `something.a = "anotherValue"`
might or might not be relying on value semantics. After refactoring, the
developer would have no choice but to read every line with `something` and
judge whether value semantics was assumed or it was irrelevant. Really
error prone. Any mistake would result in unintended reference sharing, race
conditions etc. The actual bug might surface far from the originating issue.

> "hu?  Just check if the type is a struct or a enum! So will be a value
type. Whats the problem here?"

Of course, but you'd have to pause reading and jump to the definition each
time. And keep two mental models when structures and classes are used
together.

> "No, the whole point of structs are not to be used in small and simple
cases, not on Swift, in swift um Swift are first class citizen and can be
use for complex data structure, like Array and Strings. You can make a
private shared buffer behind the scenes."

It does certainly seem to be this way in practice. It was the impression I
got from Swift's official docs: "*The structure’s primary purpose is to
encapsulate a few relatively simple data values.". *But now I realize it
talks about other possible use cases.

> "Try this one: https://developer.apple.com/videos/play/wwdc2015-408/ ( 
> Protocol-Oriented
Programming in Swift )"

I enjoyed this one, but it's about inheritance vs. protocols. He changes
classes to structures because he thinks it fits the model but he could have
kept classes and still proved his point that protocols are more powerful
and flexible.

I called my attention though, at around 25:20m he shows
`diagram.elements.append(diagram)` and says:* "**Now, it took me a second
to realize why Drawing wasn't going into an infinite recursion at this
point"*. That's kind of my point, these little surprises sprinkled around
the code.

Brent Royal-Gordon:

> "In a regular method, `self` is a regular (constant) parameter, but in a
`mutating` method, `self` is `inout` so that it can be mutated and those
mutations will reach the caller's copy of the instance. There's no need for
an `inout` `self` on reference types, because the mutations are performed
on the shared instance which both the caller and callee have a reference
to, so `mutating` only really makes sense for value types."

But the `mutating` keyword isn't really needed to make `self` work this way
for structures. It's actually not strictly needed at all. Another thing the
`mutating` keyword "allows" is for the method to be able to reassign
properties. I was advocating that `mutating` had only that meaning in order
to be more consistent. Then it would be equally useful for classes to make
APIs more clear with respect to mutation.


On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon 
wrote:

> > However I could probably still agree with you if mutating was also used
> in classes. What's the point of having it only on structures?
>
> In a regular method, `self` is a regular (constant) parameter, but in a
> `mutating` method, `self` is `inout` so that it can be mutated and those
> mutations will reach the caller's copy of the instance. There's no need for
> an `inout` `self` on reference types, because the mutations are performed
> on the shared instance which both the caller and callee have a reference
> to, so `mutating` only really makes sense for value types.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Adding custom attributes

[Dmitri Gribenko via swift-evolution]

On Sat, Dec 26, 2015 at 4:24 PM, James Campbell  wrote:
> Maybe we could implement a template system like C++

Sorry, it is not clear what you're hinting at, please elaborate.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

What about templatetype ? This could also work if we started referring
generics as Templates :) and extended them to protocols and functions.


On Sat, Dec 26, 2015 at 3:15 PM, Ross O'Brien 
wrote:

> There's a problem here because associated types aren't the same as
> generics.
>
> I've been looking this up a lot recently because I've been trying to
> create a delegate protocol for a generic type. The GenericType requires
> a GenericTypeDelegate and Swift 2 protocols just don't support those
> yet; the best workaround of the moment seems to be a wrapper type which
> wraps the delegate's functions in closures.
>
> This is a different concept to associated types. I've seen a couple of
> examples around; the one I'm remembering at the moment involves a protocol
> for Animals requiring them to have an associated Food type. A Cow could
> thus be defined as a type implementing the Animal protocol, with an
> associated type of Grass; this would be very different to an Animal being a
> generic type, and a Cow being (perhaps typealiased as) an Animal.
> With the associated type, the Cow is known to always eat Grass; with the
> generic type, every function is written to handle all foodstuffs.
>
> So, no, the two different syntaxes are required - but protocols with
> generic parameters (is that the right term for e.g. Grass in
> Animal?) would be a good addition to the language.
>
>
> On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> If we made class, structs, protocols and functions use the same generics
>> syntax then I think it would make it more consistent rather than arguing
>> about which keyword to use. I am for-ever being tripped up by lack of
>> generics in the language.
>>
>> class Array
>> {
>> func first() -> T?
>> }
>>
>> struct Node
>> {
>> var value: Value
>> }
>>
>> Array()
>> Node()
>>
>> or
>>
>> func makeACell() -> T
>> {
>> }
>>
>> makeACell()
>>
>> or
>>
>> protocol Collection
>> {
>> func first() -> Item?
>> }
>>
>> class IntBag : Collection //We bind protocol "associated type" using
>> generic syntax when subclassing. In this case we are saying Item should be
>> type Int
>> {
>> }
>>
>> class Array: Collection //We bind protocol "associated type"
>> using generic syntax when subclassing. In this case we are saying Item
>> should be the same type as the generic type for Array
>> {
>> }
>>
>> IntBag()
>> Array()
>>
>>
>> On Wed, Dec 23, 2015 at 10:58 PM, James Campbell 
>> wrote:
>>
>>> They are placeholders because in the protocol:
>>>
>>> prtocotol Collection
>>> {
>>>   placeholder Item
>>>
>>>   func first() -> Item?
>>>  {
>>>  }
>>> }
>>>
>>> Item is a placeholder for a concrete type, at this moment this is a
>>> concept "A collection should return an item of a type" but we don't know
>>> what that type is as its a plaeholder for a type.
>>>
>>> therefore in:
>>>
>>> class IntCollection: Collection
>>> {
>>>placeholder Item = Int
>>> }
>>>
>>> We are saying that the placeholder should now become a concrete type. In
>>> my eyes associated types are nothing more than generics for protocols which
>>> in turn could be argued is some kind of placeholder.
>>>
>>> Associated type means nothing to me, associated to what ? A type could
>>> be associated to many things like a variable, or a generic or whatever. A
>>> placeholder to mean does what it says on the tin. If we moved to protocols
>>> using a syntax closer to generics for classes then I think it would be
>>> simpilar to grasp for beginners .
>>>
>>> On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose 
>>> wrote:
>>>
 James or Erica (or someone else), can you explain what makes these
 types "placeholders"? I don't think of the other requirements in a protocol
 as "placeholder properties" or "placeholder methods".

 My explanation of these things is "When a particular type X conforms to
 a protocol, you can ask about the types that X uses to implement the
 requirements of the protocol". I guess we could call them "related types"
 instead of "associated types", but that doesn't seem significantly
 different.

 Jordan


 > On Dec 23, 2015, at 12:42, James Campbell via swift-evolution <
 swift-evolution@swift.org> wrote:
 >
 > The thing is associated type means nothing to me, it's too technical.
 Placeholder type I think would be better even if it's only what we called
 it in the documentation
 >
 > Sent from my iPhone


>>>
>>>
>>> --
>>>  Wizard
>>> ja...@supmenow.com
>>> +44 7523 279 698
>>>
>>
>>
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
ht

Re: [swift-evolution] Adding custom attributes

[James Campbell via swift-evolution]

Maybe we could implement a template system like C++

On Sat, Dec 26, 2015 at 3:20 PM, Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura 
> wrote:
> > So,
> >
> > What do you think about syntax like this:
> >
> > // Declaration
> > @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into
> binary
> > @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
> > @attribute JSONProperty {
> > var name:String!;
> > var serializable:Bool? = true;
> > var deserializable:Bool? = true;
> > }
>
> Is this a new declaration kind?  Do you think we could make it work
> with existing language constructs instead, like structs?  Any
> downsides to that?
>
> > // Usage
> > @JSONProperty(name=“id”)
> > var id:Int;
> >
> >
> > Attributes should be module aware (actual attributes should be redefined
> as Swift attribute, for beginning still can be hardcoded).
>
> Sorry, I'm not sure what this means.
>
> > The attribute’s name have to be unique in module. It’s compile time
> error if attribute, class, enum, struct, etc has same name.
> >
> > Attribute’s properties are read only and can’t be assigned - so during
> reflection no-one would change ‘shared’ values.
>
> I think using structs and requiring that attributes are value types
> would solve both issues.
>
> > Attribute’s properties can only support basic types: primitives,
> strings, types, and other attributes (optional).
>
> Well, there is no such thing as "basic types" in Swift.  Strings,
> integers etc. are defined in the standard library and the compiler
> does not know anything special about them.
>
> > When declaring attributes, properties can be set to constant values
> (static let) or enum values, however the final value is stored in binary,
> not a reference to it.
>
> Again, given that strings are defined in the standard library, and
> that the language does not have a notion of a constant expression, I'm
> not sure how this would work.  I'm not saying it can't, I'm just
> saying you need to introduce a lot of new language concepts and
> compiler machinery.
>
> > The compiler has build in support for core attributes, which can affect
> code generation. Compiler may perform additional checks on core attributes.
>
> OK.
>
> Another question is, how would you inspect attributes at runtime?
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Adding custom attributes

[Dmitri Gribenko via swift-evolution]

On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura  wrote:
> So,
>
> What do you think about syntax like this:
>
> // Declaration
> @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into binary
> @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
> @attribute JSONProperty {
> var name:String!;
> var serializable:Bool? = true;
> var deserializable:Bool? = true;
> }

Is this a new declaration kind?  Do you think we could make it work
with existing language constructs instead, like structs?  Any
downsides to that?

> // Usage
> @JSONProperty(name=“id”)
> var id:Int;
>
>
> Attributes should be module aware (actual attributes should be redefined as 
> Swift attribute, for beginning still can be hardcoded).

Sorry, I'm not sure what this means.

> The attribute’s name have to be unique in module. It’s compile time error if 
> attribute, class, enum, struct, etc has same name.
>
> Attribute’s properties are read only and can’t be assigned - so during 
> reflection no-one would change ‘shared’ values.

I think using structs and requiring that attributes are value types
would solve both issues.

> Attribute’s properties can only support basic types: primitives, strings, 
> types, and other attributes (optional).

Well, there is no such thing as "basic types" in Swift.  Strings,
integers etc. are defined in the standard library and the compiler
does not know anything special about them.

> When declaring attributes, properties can be set to constant values (static 
> let) or enum values, however the final value is stored in binary, not a 
> reference to it.

Again, given that strings are defined in the standard library, and
that the language does not have a notion of a constant expression, I'm
not sure how this would work.  I'm not saying it can't, I'm just
saying you need to introduce a lot of new language concepts and
compiler machinery.

> The compiler has build in support for core attributes, which can affect code 
> generation. Compiler may perform additional checks on core attributes.

OK.

Another question is, how would you inspect attributes at runtime?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Ross O'Brien via swift-evolution]

There's a problem here because associated types aren't the same as generics.

I've been looking this up a lot recently because I've been trying to create
a delegate protocol for a generic type. The GenericType requires a
GenericTypeDelegate and Swift 2 protocols just don't support those yet;
the best workaround of the moment seems to be a wrapper type which wraps
the delegate's functions in closures.

This is a different concept to associated types. I've seen a couple of
examples around; the one I'm remembering at the moment involves a protocol
for Animals requiring them to have an associated Food type. A Cow could
thus be defined as a type implementing the Animal protocol, with an
associated type of Grass; this would be very different to an Animal being a
generic type, and a Cow being (perhaps typealiased as) an Animal.
With the associated type, the Cow is known to always eat Grass; with the
generic type, every function is written to handle all foodstuffs.

So, no, the two different syntaxes are required - but protocols with
generic parameters (is that the right term for e.g. Grass in
Animal?) would be a good addition to the language.


On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution <
swift-evolution@swift.org> wrote:

> If we made class, structs, protocols and functions use the same generics
> syntax then I think it would make it more consistent rather than arguing
> about which keyword to use. I am for-ever being tripped up by lack of
> generics in the language.
>
> class Array
> {
> func first() -> T?
> }
>
> struct Node
> {
> var value: Value
> }
>
> Array()
> Node()
>
> or
>
> func makeACell() -> T
> {
> }
>
> makeACell()
>
> or
>
> protocol Collection
> {
> func first() -> Item?
> }
>
> class IntBag : Collection //We bind protocol "associated type" using
> generic syntax when subclassing. In this case we are saying Item should be
> type Int
> {
> }
>
> class Array: Collection //We bind protocol "associated type"
> using generic syntax when subclassing. In this case we are saying Item
> should be the same type as the generic type for Array
> {
> }
>
> IntBag()
> Array()
>
>
> On Wed, Dec 23, 2015 at 10:58 PM, James Campbell 
> wrote:
>
>> They are placeholders because in the protocol:
>>
>> prtocotol Collection
>> {
>>   placeholder Item
>>
>>   func first() -> Item?
>>  {
>>  }
>> }
>>
>> Item is a placeholder for a concrete type, at this moment this is a
>> concept "A collection should return an item of a type" but we don't know
>> what that type is as its a plaeholder for a type.
>>
>> therefore in:
>>
>> class IntCollection: Collection
>> {
>>placeholder Item = Int
>> }
>>
>> We are saying that the placeholder should now become a concrete type. In
>> my eyes associated types are nothing more than generics for protocols which
>> in turn could be argued is some kind of placeholder.
>>
>> Associated type means nothing to me, associated to what ? A type could be
>> associated to many things like a variable, or a generic or whatever. A
>> placeholder to mean does what it says on the tin. If we moved to protocols
>> using a syntax closer to generics for classes then I think it would be
>> simpilar to grasp for beginners .
>>
>> On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose 
>> wrote:
>>
>>> James or Erica (or someone else), can you explain what makes these types
>>> "placeholders"? I don't think of the other requirements in a protocol as
>>> "placeholder properties" or "placeholder methods".
>>>
>>> My explanation of these things is "When a particular type X conforms to
>>> a protocol, you can ask about the types that X uses to implement the
>>> requirements of the protocol". I guess we could call them "related types"
>>> instead of "associated types", but that doesn't seem significantly
>>> different.
>>>
>>> Jordan
>>>
>>>
>>> > On Dec 23, 2015, at 12:42, James Campbell via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> > The thing is associated type means nothing to me, it's too technical.
>>> Placeholder type I think would be better even if it's only what we called
>>> it in the documentation
>>> >
>>> > Sent from my iPhone
>>>
>>>
>>
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>>
>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
> ___
> 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 - Allow properties in Extensions

[Matthew Johnson via swift-evolution]

> On Dec 25, 2015, at 12:02 AM, John McCall  wrote:
> 
>> On Dec 24, 2015, at 12:10 PM, Matthew Johnson  wrote:
>>> On Dec 24, 2015, at 2:05 PM, John McCall  wrote:
>>> 
 On Dec 24, 2015, at 11:48 AM, Matthew Johnson  
 wrote:
> On Dec 24, 2015, at 1:31 PM, John McCall  wrote:
> 
> 
>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson  
>> wrote:
>> 
>> 
 On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution 
  wrote:
 
 On Dec 23, 2015, at 7:05 AM, Paul Cantrell  wrote:
> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution 
>  wrote:
> 
> when you stuff a lot of functionality into a single class in most OO 
> languages, there’s no real way to enforce its division into 
> subsystems, because every method has direct access to every property 
> and every other method.  In contrast, in Swift you can divide that 
> class into distinct components with their own interface, state, and 
> invariants, essentially making each component as good as its own type 
> as far as encapsulation goes.
 
 Can you elaborate on this, John? Extensions and protocols in Swift 
 today still don’t solve the problem that shared _private_ class state 
 has to be centralized. Or were you speaking as if this “properties in 
 extensions” proposal were already implemented?
>>> 
>>> Yes, that’s right.  I’m explaining why I think it makes sense to limit 
>>> stored instance properties in extensions to class types: especially 
>>> with some solution for private initialization of extensions, they 
>>> enable intra-class encapsulation in a way that matters for classes and 
>>> not really for other types.
>> 
>> How would private initialization of extensions work?
> 
> Just spit-balling, but something like:
> 
> class A {
> init(numbers: [Int]) {
>   // Definitive initialization requires initialization of all the 
> extensions
>   // in the module that declare partial inits before the call to 
> super.init.
>   self.init(counts: numbers)
> 
>   // Okay, now we super.init.
>   super.init()
> 
>   // Fully initialized now.
> }
> }
> 
> extension A {
> let counts: [Int]
> partial init(counts: [Int]) {
>  // Definitive initialization requires a partial init to initialize all 
> the stored properties
>  // in this extension.  This all happens prior to the complete 
> initialization of self,
>  // so unlike a normal init, there is no point in this initializer when 
> unrestricted
>  // use of self is allowed.  If that’s required, it can be done with an 
> ordinary method
>  // call.
>  //
>  // To start, partial initializers would not be allowed to use properties 
> from other
>  // extensions or the main class.  We can consider ways to lift that 
> restriction later.
> 
>  self.counts = counts
> }
> }
 
 I'm really not sure I like this very much.  It seems to be exactly what I 
 was concerned about.  The primary advantage this seems to provide is 
 encapsulation for the extension.  Unfortunately it also means the 
 extension has a ripple effect requiring initializers elsewhere in the 
 project to be updated.  This doesn't feel like an "extension" as it 
 actually seems to be pretty invasive.  It gives me an uneasy feeling at 
 first glance.
>>> 
>>> Any proposal which allows stored properties with non-default initialization 
>>> to be added in an extension is going to require source changes to the main 
>>> class initializer(s).  My suggestion of partial inits achieves that without 
>>> breaking encapsulation, which in my judgment would not be acceptable.  You 
>>> could also just require all stored properties in extensions to have a 
>>> default initializer, which is the rule we’d be forced to use outside the 
>>> module anyway.  These are your options if you actually care about this 
>>> feature.
>> 
>> Understood.  I’m still trying to asses how I feel about the idea in general. 
>>  There are certainly advantages, but there are also drawbacks, particularly 
>> when the stored properties aren’t required to have defaults.
> 
> Here’s the key argument for me.  What is the point of an extension of a 
> concrete type within the defining module? Extending a *protocol* has a lot of 
> expressive power, sure.  Extending a *different* module’s type lets you avoid 
> awkward workarounds and makes code feel more consistent, sure.  But extending 
> your own type, when you could have just written that code in the main 
> definition?  It would surely reduce language complexity if we disallowed 
> that. And yet, people still want to do it, even though the only reason to do 
> so is code organization.   Something about the code in the extension fee

Re: [swift-evolution] Adding custom attributes

[Radosław Smogura via swift-evolution]

So,

What do you think about syntax like this:

// Declaration
@AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into binary
@AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
@attribute JSONProperty {
var name:String!;
var serializable:Bool? = true;
var deserializable:Bool? = true;
}

// Usage
@JSONProperty(name=“id”)
var id:Int;


Attributes should be module aware (actual attributes should be redefined as 
Swift attribute, for beginning still can be hardcoded).

The attribute’s name have to be unique in module. It’s compile time error if 
attribute, class, enum, struct, etc has same name. 

Attribute’s properties are read only and can’t be assigned - so during 
reflection no-one would change ‘shared’ values.

Attribute’s properties can only support basic types: primitives, strings, 
types, and other attributes (optional). 

When declaring attributes, properties can be set to constant values (static 
let) or enum values, however the final value is stored in binary, not a 
reference to it.

The compiler has build in support for core attributes, which can affect code 
generation. Compiler may perform additional checks on core attributes.

Attributes on attributes (optional).

Best regards,
Radek

> On 26 Dec 2015, at 13:35, Dmitri Gribenko  wrote:
> 
> On Sat, Dec 26, 2015 at 12:55 PM, Radosław Smogura
>  wrote:
>> Hello Swift Team,
>> 
>> As it’s my first post on this mailing list, let me introduce my self. My 
>> name is Radek Smogura, and for 10 year I work as developer, mainly Java and 
>> I know C and C++. I would like to join Swift community and work on Swift 
>> language. Previously for hobby I  added properties syntax to it and full 
>> closure support (you can find it here 
>> https://bitbucket.org/radoslaw_smogura/java-closures-silver-jdk9-langtools/wiki/Home).
>> 
>> I would like to propose custom attributes support, as it would make Swift 
>> more robust language, by allowing dependency injection and managed objects 
>> (ie. for Core Data or some trivial example like defining JSON structures for 
>> REST). I would as well to contribute to this feature to Swift language if 
>> possible as fork or branch.
> 
> Custom attributes are an interesting direction that already came up on
> this list, but there was no concrete proposal with syntax and
> semantics.  Before you spend time implementing something extensive, I
> would strongly recommend you to float the idea on swift-evolution, and
> follow-up with a formal proposal if there is consensus.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-evolution] Adding custom attributes

[Dmitri Gribenko via swift-evolution]

On Sat, Dec 26, 2015 at 12:55 PM, Radosław Smogura
 wrote:
> Hello Swift Team,
>
> As it’s my first post on this mailing list, let me introduce my self. My name 
> is Radek Smogura, and for 10 year I work as developer, mainly Java and I know 
> C and C++. I would like to join Swift community and work on Swift language. 
> Previously for hobby I  added properties syntax to it and full closure 
> support (you can find it here 
> https://bitbucket.org/radoslaw_smogura/java-closures-silver-jdk9-langtools/wiki/Home).
>
> I would like to propose custom attributes support, as it would make Swift 
> more robust language, by allowing dependency injection and managed objects 
> (ie. for Core Data or some trivial example like defining JSON structures for 
> REST). I would as well to contribute to this feature to Swift language if 
> possible as fork or branch.

Custom attributes are an interesting direction that already came up on
this list, but there was no concrete proposal with syntax and
semantics.  Before you spend time implementing something extensive, I
would strongly recommend you to float the idea on swift-evolution, and
follow-up with a formal proposal if there is consensus.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Adding custom attributes

[Radosław Smogura via swift-evolution]

Hello Swift Team,

As it’s my first post on this mailing list, let me introduce my self. My name 
is Radek Smogura, and for 10 year I work as developer, mainly Java and I know C 
and C++. I would like to join Swift community and work on Swift language. 
Previously for hobby I  added properties syntax to it and full closure support 
(you can find it here 
https://bitbucket.org/radoslaw_smogura/java-closures-silver-jdk9-langtools/wiki/Home).

I would like to propose custom attributes support, as it would make Swift more 
robust language, by allowing dependency injection and managed objects (ie. for 
Core Data or some trivial example like defining JSON structures for REST). I 
would as well to contribute to this feature to Swift language if possible as 
fork or branch.

My general high level plan is as follow:
- add experimental feature switch to add parsing custom attributes,
- define and implement attribute syntax,
- compile attributes and store those,
- add validation and compilation to attribute declarations
- - (optionally) refactor current code
- enjoy.

Waiting for your thoughts,
Radek


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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Tino Heth via swift-evolution]

> Sorry if this has been discussed and I missed it, but Scala and Kotlin both 
> support a compact function-like class declaration syntax for simple "case 
> classes".

Just took some time to read more deeply and would have added a reference to 
Kotlin on my own — I think their approach of solving the problem from the other 
direction (turning parameters into members instead of inferring parameters for 
properties) feels quite natural and avoids many problems; but unless the 
decision to remove var parameters is revised, I think it's unfortunate to 
introduce them in another context.
We shouldn't forget that initializers in Swift already are a quite huge and 
complicated topic (required, convenience, when to call super…) with big 
potential to confuse newcomers; so I'd recommend to be careful introducing new 
keywords and concepts that aren't useful in other places and rather stick with 
a less complete solution that is lightweight and elegant:
It could be considered to simply don't address parts of the problem in the 
language at all, but encourage better tools to manage the boilerplate.

Merry christmas!
Tino

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

[swift-evolution] Support for custom attributes

[JOSE MARIA GOMEZ CAMA via swift-evolution]

Dear all,

I am quite new to Swift, though I have made some small checks within Xcode, so 
I could have missed some feature in swift that provides a functionality similar 
to the want I am proposing.

I have been using my own annotations in Java or decorators in Python, and I 
would like to have an equivalent functionality in Swift. As far as I have seen, 
there are attributes that can provide a similar solution, but AFAIK you cannot 
create new ones. Would it be possible to add this feature in Swift.

Thanks in advance,

Jose M.



Aquest correu electrònic i els annexos poden contenir informació confidencial o 
protegida legalment i està adreçat exclusivament a la persona o entitat 
destinatària. Si no sou el destinatari final o la persona encarregada de 
rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, 
distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si heu rebut aquest 
correu electrònic per error, us preguem que n’informeu al remitent i que 
elimineu del sistema el missatge i el material annex que pugui contenir. 
Gràcies per la vostra col·laboració.

Este correo electrónico y sus anexos pueden contener información confidencial o 
legalmente protegida y está exclusivamente dirigido a la persona o entidad 
destinataria. Si usted no es el destinatario final o la persona encargada de 
recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo, 
copiarlo ni a revelar su contenido. Si ha recibido este mensaje electrónico por 
error, le rogamos que informe al remitente y elimine del sistema el mensaje y 
el material anexo que pueda contener. Gracias por su colaboración.

This email message and any documents attached to it may contain confidential or 
legally protected material and are intended solely for the use of the 
individual or organization to whom they are addressed. We remind you that if 
you are not the intended recipient of this email message or the person 
responsible for processing it, then you are not authorized to read, save, 
modify, send, copy or disclose any of its contents. If you have received this 
email message by mistake, we kindly ask you to inform the sender of this and to 
eliminate both the message and any attachments it carries from your account. 
Thank you for your collaboration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Epic: Typesafe calculations

[Tino Heth via swift-evolution]

> If Swift would support non-type generic parameters, then I would like to have 
> Boost.Unit library 
> (http://www.boost.org/doc/libs/1_60_0/doc/html/boost_units.html 
> ) available 
> in Swift.
To be honest, "non-type generic parameters" were plant as the final step in the 
whole topic — they would not only help with units, but also give us safe vector 
math. Just avoid the "T"-word and the language boost was written for; those can 
trigger unwanted reflexes ;-)

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

[swift-evolution] Pitch: Guard for declaration

[Angelo Villegas via swift-evolution]

Hi Everyone,

Back in the ternary discussion, I kinda suggested the use of Guard but then I 
realised it’s not a replacement for ternary nor an alternative, it should not 
be, but may be a helpful addition to Swift.

let a | x > 0 && x < 10 = “less than ten”
  | x > 10 && < 100 = “less than a hundred”
  | x > 100 = “more than a hundred”
  | otherwise = “probably a negative”

There’s someone who said that it’s reasonable in declarations and another said 
that he like to explore using the bar (or pipe) character (|).

The where clause should work well with declarations. For instance, consider a 
function which computes the number of solutions for a quadratic equation, ax^2 
+ bx + c = 0

let num | disc > 0  = 2
| disc == 0 = 1
| otherwise = 0
where
disc = a2 + b + c
where
a = 2 * 1
b = 2 + 3
c = 6 / 2

I believe it may also help lessen the number of lines (in many cases) from 
using if-else-if and/or switch statements.

Anyway, I just thought to start a pitch. If people will like the idea we might 
give a proper proposal for the boolean guard.

- Angelo

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