> On May 23, 2016, at 10:52 AM, Kevin Nattinger via swift-evolution > <[email protected]> wrote: > > Discussed last month > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html > And (linked from that thread) last year > http://article.gmane.org/gmane.comp.lang.swift.evolution/727 > > I think it’s a good idea, but discussion seems to have just petered out > without a formal proposal both times.
This didn’t peter out. My opinion on this topic evolved throughout the review. The perspective I came to is that the best approach may require changes that are outside the scope of Swift 3. I expect this to come up again during the Swift 4 conversation. > > How about we just apply the struct auto-init behavior to classes? It’s nice > and simple, and already in the language. > >> On May 23, 2016, at 7:29 AM, Charlie Monroe via swift-evolution >> <[email protected]> wrote: >> >> A lot of initializers tediously assign values to variables which results in >> a lot of code such as self.variable = arg1 (or even worse variable = >> variable), mostly for classes that are meant to just encapsulate several >> values. >> >> I propose adding auto keyword (to be discussed - anyone has a better name in >> mind?), which would automatically assign same-named variables. Example: >> >> class User { >> var name: String >> var password: String >> >> init(auto name: String, auto password: String) { >> // No assignment required, the variables will be automatically >> assigned. >> // Perform additional init stuff here. >> } >> } >> >> This would, of course, work only if the argument has the same name as a >> stored variable on the class. >> >> Additionally, if the class is root, or the superclass has an initializer >> that takes no arguments, I propose adding @auto_init annotation, which would >> generate a default initializer, similar to what is done for structs: >> >> @auto_init >> class User { >> var name: String >> var password: String >> } >> >> Normally, such class would be illegal since it would have no accessible >> initializers. The annotation could specify the access control as well: >> @auto_init(private), @auto_init(internal), @auto_init(public). >> >> If the class isn't root, but inherits from an object that has an initializer >> that takes no arguments (e.g. NSObject), this would be allowed as well and >> the initializer with no arguments would be called on super. >> >> Any thoughts on this? Sorry, if this has been already discussed. >> >> Charlie >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
