Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

It's not a matter of probability, but rather of certainty. Please. On Mon, 26 Dec 2016 at 12:56 Xiaodi Wu wrote: > On Mon, Dec 26, 2016 at 2:19 AM, Daniel Leping > wrote: > > I totally agree Swift is an opinionated language and it's good. > > Also

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I totally agree Swift is an opinionated language and it's good. Also I have been thinking of DefaultConstructable vs reflection for generic factories and I would prefer to stick to the protocol as it gives compile time type safety check. With reflection the only way is to through an exception if

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Well, AnyObject exists on Linux with no bridging. Still it's IMPLICITELY conformed by all classes. What you say is just another approach to the same issue and we can argue for eternity. However, I am very positive with syntactic sugar and this one falls exactly to sugar category. Make people

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping wrote: > I believe you're confusing in-class factory methods with factory pattern. > > Factories can be separate objects and it's a very different situation. > Fair, but I understand both to fall under the umbrella of "any

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I believe you're confusing in-class factory methods with factory pattern. Factories can be separate objects and it's a very different situation. On Mon, 26 Dec 2016 at 11:46 Xiaodi Wu wrote: > On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping >

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Mon, Dec 26, 2016 at 12:55 AM, Daniel Leping wrote: > Ok, an example: > > func myFactory(c:T.Type) -> T { > let t = T() > > if let ini = t as? Initializable { > ini.initialize(self) > } > > if let co = t as? ContextAware { > co.setContext(context) > } > > //etc > >

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping wrote: > I'm not arguing for implicit conformance in general, but I'm telling that > DefaultConstructable is the same basic level as AnyObject, which is > conformed implicitly. > > Shortly, I'm against implicit conformance

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Ok, an example: func myFactory(c:T.Type) -> T { let t = T() if let ini = t as? Initializable { ini.initialize(self) } if let co = t as? ContextAware { co.setContext(context) } //etc return t } On Mon, 26 Dec 2016 at 11:19 Daniel Leping wrote: > I'm not arguing

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I'm not arguing for implicit conformance in general, but I'm telling that DefaultConstructable is the same basic level as AnyObject, which is conformed implicitly. Shortly, I'm against implicit conformance in general. I'm positive with "automatic compiler magic" conformance to

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > Thank you, Adam! > Wait, are you arguing for implicit conformance or not? On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution < > swift-evolution@swift.org> wrote: > >> > Swift

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Thank you, Adam! On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution < swift-evolution@swift.org> wrote: > > Swift doesn't do implicit conformance. It always has to be declared > explicitly. I'm pretty sure Doug Gregor can explain why better than I > could. > > > I don't think Daniel

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

> Swift doesn't do implicit conformance. It always has to be declared explicitly. I'm pretty sure Doug Gregor can explain why better than I could. I don't think Daniel was arguing for implicit conformance, he's saying that if it makes sense for an object to have a default constructor, it makes

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

I'm not against explicit protocol conformance for custom stuff, but doesn't default constructor look like a very common use case? Again, I'm completely against implicit conformance for custom stuff, but this one is of the same level as AnyObject implicit conformance. It's an exception, isn't it?

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

on Sun Dec 25 2016, Daniel Leping wrote: > You are right, usually it's required to implement a protocol which is not a > good approach. The best is plain objects which can be used independently of > ORM if needed (as DTOs, i.e.). > > I was thinking of

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

This is a very old discussion that took plays years ago with POJO vs JavaBean approach. For sure, extensions give us a bit more flexibility, though the subject remains the same. Extensions are not a panacea and I think we should always look back for good proven patterns rather than reinvent the

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Ok, which approach is easier? Plain struct working out of the box or adding an additional conformance? I like the usage be as easy as possible and as less effort as possible. On Mon, 26 Dec 2016 at 10:20 Xiaodi Wu wrote: > On Sun, Dec 25, 2016 at 11:46 PM, Daniel Leping

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

on Sun Dec 25 2016, Xiaodi Wu wrote: > On Sun, Dec 25, 2016 at 9:40 PM, Adam Nemecek > wrote: > >> > Yes, those particular types have initializers that take no arguments. >> That does not address my question. You merely restated your initial >>

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

on Sun Dec 25 2016, Xiaodi Wu wrote: > On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek > wrote: > >> There's a book that provides quite a bit of info on this >> >> https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/ >>

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

on Sun Dec 25 2016, Xiaodi Wu wrote: > On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek > wrote: > >> There's a book that provides quite a bit of info on this >> >> https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/ >>

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping wrote: > Usually it's a generic function that needs to return a value from some > other function or a default value (zero) in a case of some conditions. > Optional value is an arguable solution in quite some scenarios.

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 9:40 PM, Adam Nemecek wrote: > > Yes, those particular types have initializers that take no arguments. > That does not address my question. You merely restated your initial > observation that many types in Swift have implemented `init()`. > > Right,

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Usually it's a generic function that needs to return a value from some other function or a default value (zero) in a case of some conditions. Optional value is an arguable solution in quite some scenarios. Afaik, sometimes it can be used for optional resolution. Also, generic factories. Widely

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Can you give some examples of what you used this approach to do? On Sun, Dec 25, 2016 at 9:49 PM, Daniel Leping wrote: > +1 to this approach. I remember I had to create it on my own for my > projects. Would be nice to have it out of the box. > > On Mon, 26 Dec 2016 at

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 9:40 PM, Adam Nemecek wrote: > > Yes, those particular types have initializers that take no arguments. > That does not address my question. You merely restated your initial > observation that many types in Swift have implemented `init()`. > > Right,

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

+1 to this approach. I remember I had to create it on my own for my projects. Would be nice to have it out of the box. On Mon, 26 Dec 2016 at 8:11 Adam Nemecek via swift-evolution < swift-evolution@swift.org> wrote: > > Yes, those particular types have initializers that take no arguments. > That

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

> Yes, those particular types have initializers that take no arguments. That does not address my question. You merely restated your initial observation that many types in Swift have implemented `init()`. Right, it's an empirical argument. > I didn't think the value returned by `init()` was

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 7:30 PM, Adam Nemecek wrote: > > Is it well settled, either in Swift or in C++/Rust/etc., that the value > returned by a default initializer/constructor is regarded as an identity > element or zero? > > Int() == 0, String() == "" so to some extent

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

> Is it well settled, either in Swift or in C++/Rust/etc., that the value returned by a default initializer/constructor is regarded as an identity element or zero? Int() == 0, String() == "" so to some extent by convention, a lot of types have a default value as is. > Is the thread that I get

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 5:27 PM, Adam Nemecek wrote: > > *Which* APIs become more ergonomic? > > I'll get back to this question in a second if I may. This would be a > longer discussion and I first want to make sure that before we get into the > details that there is a

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

> *Which* APIs become more ergonomic? I'll get back to this question in a second if I may. This would be a longer discussion and I first want to make sure that before we get into the details that there is a possibility of this being introduced (I'm asking if violating the no zero defaults is more

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Dec 25, 2016, at 12:54 PM, Adam Nemecek via swift-evolution wrote: > Does enabling a lot of small improvements that make APIs more ergonomic count > as practical? Yes, that would count as practical, but Xiaodi’s question is just as important. *Which* APIs become

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Does enabling a lot of small improvements that make APIs more ergonomic count as practical? On Sun, Dec 25, 2016 at 12:19 PM, Xiaodi Wu wrote: > On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek > wrote: > >> There's a book that provides quite a bit of

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek wrote: > There's a book that provides quite a bit of info on this > > https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/ > 032163537X?sa-no-redirect=1 > > They say that DefaultConstructible is one of the

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

There's a book that provides quite a bit of info on this https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/032163537X?sa-no-redirect=1 They say that DefaultConstructible is one of the essential protocols on which most algorithms rely in one way or another. One of the authors is

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Can you give some other examples of generic algorithms that would make use of this DefaultConstructible? I'm having trouble coming up with any other than reduce. On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution < swift-evolution@swift.org> wrote: > This protocol is present in C++ >

Re: [swift-evolution] "with" operator a la O'Caml?

> On Dec 17, 2016, at 8:40 PM, Andy Chou via swift-evolution > wrote: > > I like that structs are value types in Swift, this encourages the use of > immutable data. O'Caml has an operator "with" that allows for copying an > existing struct with a change to one