Re: [swift-evolution] [Proposal] Factory Initializers

[Pranshu Goyal via swift-evolution]

Any hopes for it in future?

On 4 June 2017 at 20:40, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> No.
>
>
>
> On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Is this proposal in the pipeline for Swift 4?
>>
>> On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> First, you should fix the indent in the code samples. Second, remove any
>>> access modifier from inside a protocol. Third, we don’t support default
>>> implementations directly inside protocols yet, so that’s a not valid
>>> example.
>>>
>>> Now my personal concerns. As far as I can tell XIB files in an iOS
>>> Project are meant for UIViewControllers in first place, but it’s a common
>>> case that they are also used to create reusable UIViews. The downside of
>>> that abusage is view hierarchy clustering. Most developer creating a view
>>> of Self in Self, which smells to me like really bad code.
>>>
>>> MyCustomView // This view is useless
>>>+ MyCustomView
>>>+ CustomSubview1
>>>+ CustomSubview1 // This is probably a dead IBOutlet
>>>
>>> In fact Xcode does not use the initializer from NSCoding to show a live
>>> rendered view inside interface builder, instead it will call a UIViews
>>> designated initializer init(frame:). That results that a lot of the
>>> developer write similar code like in the following snippet:
>>>
>>> // This pattern results in a similar view cluster like mentioned above
>>>
>>> class MyCustomView : UIView {
>>> override init(frame: CGRect) {
>>> let view = loadSomehowFromNib()
>>> self.addSubview(view)
>>> }
>>> }
>>>
>>> To solve this problem we’d need some functionality of factory
>>> initializers. I believe as proposed the factory initializer won’t solve
>>> that problem, because everything would be still restricted to a special
>>> initializer annotated with factory.
>>>
>>> Personally I would want to write something like this instead.
>>>
>>> class MyCustomView : UIView {
>>>
>>> override init(frame: CGRect) {
>>>
>>> // Instantiating from a Nib file will call `init(coder:​)` on 
>>> MyCustomView
>>> self = loadSomehowFromNib() // assuming () -> MyCustomView
>>>
>>> //
>>> self.frame = frame
>>> }
>>> }
>>>
>>> This should resolve the clustering issue by assigning the returned
>>> instance from the function to self and create a correct view hierarchy.
>>>
>>> + MyCustomView
>>>+ CustomSubview1
>>>
>>>
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
>>> swift-evolution@swift.org) schrieb:
>>>
>>> Hi again everyone!
>>>
>>> Now that Swift 4 Stage 2 proposals are being considered, I thought it
>>> might be time to revisit this proposal and see if it might align with the
>>> goals set forth for Swift 4.
>>>
>>> As a quick tl;dr, this proposal describes a new "factory initializer"
>>> that would allow you to return a value from an initializer. This would have
>>> several benefits, as mentioned in the proposal itself as well as throughout
>>> this mailing list. For convenience, here's a link to the proposal on
>>> GitHub: https://github.com/rileytestut/swift-evolution/
>>> blob/master/proposals/-factory-initializers.md
>>>
>>> Would love to hear any more comments on this proposal, and if we feel
>>> this is appropriate for considering for Swift 4 I'll happily re-open the
>>> pull request!
>>>
>>> Riley Testut
>>>
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian <ark...@icloud.com>
>>> wrote:
>>>
>>> i would appreciate this feature.
>>>
>>> For unexperienced developers, its often hard to recognize *when* factory
>>> is a good fit to do the job, and how exactly approach the implementation. I
>>> imagine having this feature built into the language may help to choose and
>>> implement factory when its the right thing to do.
>>>
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
>>> swif

Re: [swift-evolution] [Proposal] Factory Initializers

[Pranshu Goyal via swift-evolution]

Is this proposal in the pipeline for Swift 4?

On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> First, you should fix the indent in the code samples. Second, remove any
> access modifier from inside a protocol. Third, we don’t support default
> implementations directly inside protocols yet, so that’s a not valid
> example.
>
> Now my personal concerns. As far as I can tell XIB files in an iOS Project
> are meant for UIViewControllers in first place, but it’s a common case that
> they are also used to create reusable UIViews. The downside of that abusage
> is view hierarchy clustering. Most developer creating a view of Self in
> Self, which smells to me like really bad code.
>
> MyCustomView // This view is useless
>+ MyCustomView
>+ CustomSubview1
>+ CustomSubview1 // This is probably a dead IBOutlet
>
> In fact Xcode does not use the initializer from NSCoding to show a live
> rendered view inside interface builder, instead it will call a UIViews
> designated initializer init(frame:). That results that a lot of the
> developer write similar code like in the following snippet:
>
> // This pattern results in a similar view cluster like mentioned above
>
> class MyCustomView : UIView {
> override init(frame: CGRect) {
> let view = loadSomehowFromNib()
> self.addSubview(view)
> }
> }
>
> To solve this problem we’d need some functionality of factory
> initializers. I believe as proposed the factory initializer won’t solve
> that problem, because everything would be still restricted to a special
> initializer annotated with factory.
>
> Personally I would want to write something like this instead.
>
> class MyCustomView : UIView {
>
> override init(frame: CGRect) {
>
> // Instantiating from a Nib file will call `init(coder:​)` on 
> MyCustomView
> self = loadSomehowFromNib() // assuming () -> MyCustomView
>
> //
> self.frame = frame
> }
> }
>
> This should resolve the clustering issue by assigning the returned
> instance from the function to self and create a correct view hierarchy.
>
> + MyCustomView
>+ CustomSubview1
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hi again everyone!
>
> Now that Swift 4 Stage 2 proposals are being considered, I thought it
> might be time to revisit this proposal and see if it might align with the
> goals set forth for Swift 4.
>
> As a quick tl;dr, this proposal describes a new "factory initializer" that
> would allow you to return a value from an initializer. This would have
> several benefits, as mentioned in the proposal itself as well as throughout
> this mailing list. For convenience, here's a link to the proposal on
> GitHub: https://github.com/rileytestut/swift-evolution/
> blob/master/proposals/-factory-initializers.md
>
> Would love to hear any more comments on this proposal, and if we feel this
> is appropriate for considering for Swift 4 I'll happily re-open the pull
> request!
>
> Riley Testut
>
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>
> i would appreciate this feature.
>
> For unexperienced developers, its often hard to recognize *when* factory
> is a good fit to do the job, and how exactly approach the implementation. I
> imagine having this feature built into the language may help to choose and
> implement factory when its the right thing to do.
>
> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Is there any chance of reviving this? It seems to me that since this would
> require Swift initializers to be implemented internally in such a way that
> they can return a value (as Objective-C init methods do), it may affect ABI
> stability and thus may be germane to the current stage of Swift 4
> development.
>
>
> Charles
>
>
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Recently, I proposed the idea of adding the ability to implement the
> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we
> discussed it and came up with different approaches, it evolved into a
> functionality that I believe is far more beneficial to Swift, and
> subsequently should be the focus of its own proposal. So here is the
> improved (pre-)proposal:
>
>
> # Factory Initializers
>
>
> The "factory" pattern is common in many languages, including Objective-C.
> Essentially, instead of initializing a type directly, a method is called
> that returns an instance of the appropriate type determined by the input
> parameters. Functionally this works well, but ultimately it forces the
> client of the API to remember to call the factory method instead, rather
> than the type's initializer. This might seem like a minor gripe, but given
> that we want Swift to be as approachable as 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Pranshu Goyal via swift-evolution]

I agree with the sentiment of the proposal, it does add value to overall
efficiency of swift and make things simpler for the swift team, but as
Matthew said a blanket ban will add noise to the code. Also this particular
feature is one of those niceties about swift which makes it very welcoming
to new adopters.

If some middle ground can be proposed to this problem then I think we will
be making a lot of people happy.

On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi all,
> >
> > In a discussion about inferring parameter types from default value,
> Slava brought up some performance problems caused by type inference for
> stored properties in side types:
> >
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170313/033882.html
> >
> > Towards the end, the post mentioned that some Swift team members
> contemplated requiring types for stored properties in type declarations. I
> think this idea deserves some more attention. Hence this last minute
> idea-floating.
> >
> > In addition to solving a performance headache in implementation,
> there're always the general benefit of making type declartion more explicit
> and readable (clarity for reader should out-weigh pleasure of the author).
> Making the
> > language slightly more consistent (we are not inferring types for
> default parameter values in function anyways).
> >
> > The cons for doing this are obvious too: the inference makes the
> language feels more friendly and is, undoubtedly, a beloved feature for
> many. This would be a source breaking change.
> >
> > Just thought I'd float the idea to gather some quick reaction. What do
> y'all think?
>
> I’m willing to keep an open mind on this topic but I don’t think wholesale
> banning of inference is the right thing to do.  Here is an example of a
> case where I do not want to give up inference.  When a property is
> initialized inline by calling an initializer of a non-generic type (very
> common) any annotation is strictly redundant.
>
> struct {
> let foo = Foo()
> }
>
> Requiring a type annotation here feels very unnecessary and
> boilerplate-y.  I adds no additional clarity to a reader of the code, only
> noise.  Noise reduces clarity.  Small amounts of unnecessary or redundant
> information such as in an individual stored property declaration are not
> that big a deal.  But on balance they add up quickly and have an
> undesirable impact on the overall clarity of code.
>
> >
> > Daniel Duan
> > ___
> > 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
>



-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Pranshu Goyal via swift-evolution]

Hello Karl,

Don't you think stored properties in extensions would encourage the kind of
code you talked about. I believe may you're doing it while understanding
it's implications and also accepting the fact that it's not easy to write
UI code in a modular way, but do we want everyone to think like this?
Should we accept defeat on the face of this problem that there's no way to
write UI code in a modular way where we don't have to put everything in one
massive view controller?

I feel we would be just raising our hands up if we do it this way

On 24 March 2017 at 16:49, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 24 Mar 2017, at 10:50, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>
>
> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
>  wrote:
>
> MOTIVATION:
>
> In current Swift, a pattern has emerged among some developers, in
> order to logically group parts of a class or struct’s declaration,
> particularly around protocols:
>
> >> ...
>
>
> What do you think?
>
>
> If we wanted to allow code like this to be written we wouldn’t need a
> new keyword to do it.  You are proposing two things here:
>
> 1) Allow stored properties in same-module extensions.  This has been
> discussed in the past and is a possibility, but I suspect it is not in
> scope for consideration during Swift 4.
>
>
> Are we really expect to have stored properties in same-module extensions?
> As I remember, there a lot of questions were raised during discussions so
> for some reason *I* had a feeling that we should not expect this happens in
> near feature. Probably I missed something.
>
>
> I can see why some people might want to do stored properties in extensions
> to structure things, but personally I quite like the lack of flexibility as
> it encourages the initial type declaration to focus on what a type
> *contains*, while extensions focus on what it *does*. I've really taken
> to that style, as I now almost never declare methods or computed properties
> in an initial type declaration, unless it's a very simple one; instead
> doing all my methods and protocol conformances in their own extensions.
>
> i.e- I quite like that by the time you've finished your type declaration
> you have finalised what its size will be, and nothing else can change that,
> spreading it out feels like it could make that more confusing. It also IMO
> helps to encourage you to keep a type's contents fairly simple, as you can
> see in one place if you've made it very complicated.
>
> I suppose there's an argument for having the freedom to do it however you
> want, but I don't think spreading out across a module is a good idea;
> unless we're assuming that module in this context applies like in other
> proposals, where fileprivate is a "module" with only one file.
>
> I dunno, I just think that as a pattern the current requirement to keep
> stored properties within a type declaration enforces some good practices. I
> found it a bit jarring at first too, but after adapting to the type +
> extensions style I find I actually really like doing things that way.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> If you have a complex class (especially in UI code), you sometimes don’t
> really care about the size of the class and would prefer data to be grouped
> in broader functional groups. For example, I might like my toolbar-related
> iVars to be in one extension, and my datasource-related iVars in another,
> maybe with a couple of protocol conformances with require the odd state
> variable.
>
> Requiring all of the stored properties live in the initial declaration
> means that the code is ultimately less clear: instead of being
> locally-declared (and perhaps even privately-scoped), the variable is now
> thousands of lines away from the only place I want to access it directly
> and visible throughout my implementation for me to one day muck up its
> state.
>
> Allowing stored extensions within the same file seems like a good
> compromise to me, especially if its “trivial” to implement ;) Perhaps we
> could require such types to have some special annotation or magic
> “ExtensionVariables” item, for the benefit of readability? Just trying to
> find what you’d feel would be acceptable.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Pranshu Goyal via swift-evolution]

I agree with Haravikk, enabling stored properties in extension will lead to
abuse of the feature, and people will start putting any and everything
while modeling classes retroactively, rather than think about the real
meaning and purpose of extensions which is to provide extended
functionality or convenience methods on objects without change in its basic
structure.

If someone wishes to really make an object which has added properties they
should look into subclassing rather than extending.

On 24 March 2017 at 15:20, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>
>
> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
>  wrote:
>
> MOTIVATION:
>
> In current Swift, a pattern has emerged among some developers, in
> order to logically group parts of a class or struct’s declaration,
> particularly around protocols:
>
> >> ...
>
>
> What do you think?
>
>
> If we wanted to allow code like this to be written we wouldn’t need a
> new keyword to do it.  You are proposing two things here:
>
> 1) Allow stored properties in same-module extensions.  This has been
> discussed in the past and is a possibility, but I suspect it is not in
> scope for consideration during Swift 4.
>
>
> Are we really expect to have stored properties in same-module extensions?
> As I remember, there a lot of questions were raised during discussions so
> for some reason *I* had a feeling that we should not expect this happens in
> near feature. Probably I missed something.
>
>
> I can see why some people might want to do stored properties in extensions
> to structure things, but personally I quite like the lack of flexibility as
> it encourages the initial type declaration to focus on what a type
> *contains*, while extensions focus on what it *does*. I've really taken
> to that style, as I now almost never declare methods or computed properties
> in an initial type declaration, unless it's a very simple one; instead
> doing all my methods and protocol conformances in their own extensions.
>
> i.e- I quite like that by the time you've finished your type declaration
> you have finalised what its size will be, and nothing else can change that,
> spreading it out feels like it could make that more confusing. It also IMO
> helps to encourage you to keep a type's contents fairly simple, as you can
> see in one place if you've made it very complicated.
>
> I suppose there's an argument for having the freedom to do it however you
> want, but I don't think spreading out across a module is a good idea;
> unless we're assuming that module in this context applies like in other
> proposals, where fileprivate is a "module" with only one file.
>
> I dunno, I just think that as a pattern the current requirement to keep
> stored properties within a type declaration enforces some good practices. I
> found it a bit jarring at first too, but after adapting to the type +
> extensions style I find I actually really like doing things that way.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Pranshu Goyal via swift-evolution]

-1

I second Drew Crawford's opinion. Although I agree with some of the
critiques about the current state of access levels in swift, I don't
believe that this would be the right way to proceed.

On 21 March 2017 at 06:56, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> I disagree quite strongly with the proposal.
>
> First, the document draws conclusions without apparent supporting
> evidence, e.g.
>
> > Since the release of Swift 3, the access level change of SE–0025 was met
> with dissatisfaction by a substantial proportion of the general Swift
> community. Those changes can be viewed as actively harmful, the new
> requirement for syntax/API changes.
>
>
>- What is “dissatisfaction by a substantial proportion of the general
>Swift community”? How was this measured/determined?
>- What was done to control for the population happy with SE-0025 who
>would e.g. not be likely to take up pitchforks?
>- Who argues these changes are “actively harmful” and where were they
>during SE-0025?
>
> > subtly encourages overuse of scoped access control and discourages the
> more reasonable default
>
>
>- Who claims that scoped access is “overused” and what is their
>argument for doing so?
>- Why is “fileprivate” the “more reasonable default”? In fact neither
>fileprivate **nor** private are default (reasonable or not!). Internal
>is the default. Nor does this proposal suggest we change that. So this
>seems a very strange statement.
>
> > But is that distinction between private and fileprivate actively used by
> the larger community of Swift developers?
>
> Yes. To cite some evidence, here are codebases I actively maintain:
>
> | codebase   | private # |
> fileprivate # | ratio |
>
> ||--
> -|---|---|
>
> | "M" (proprietary)  | 486   | 249
>   | 2x|
>
> | "N"(proprietary)   | 179   | 59
>| 3x|
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   |
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   |
>
> So from my chair, not only is the distinction useful, but scoped access
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
>
> > And if it were used pervasively, would it be worth the cognitive load
> and complexity of keeping two very similar access levels in the language?
> This proposal argues that answer to both questions is no
>
> This proposal does not make any later argument about “cognitive load” or
> “complexity” I can identify.  Did the proposal get truncated?
>
> What is stated (without evidence) is that "it is extremely common to use
> several extensions within a file” and that use of “private” is annoying in
> that case.  I now extend the above table
>
> | codebase   | private # |
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
>
> ||--
> -|---|---|--
> |
>
> | "M" (proprietary)  | 486   | 249
>   | 2x| 48   |
>
> | "N"(proprietary)   | 179   | 59
>| 3x| 84   |
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   | 3|
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   | 6|
>
> in order to demonstrate in my corner of Swift this is not “extremely
> common”, and is actually less popular than language features the proposal
> alleges aren’t used.
>
> My point here is that ***different people in different corners of the
> community program Swift differently and use different styles***.  I can
> definitely empathize with folks like the author who use extensions to group
> functions and are annoyed that their favorite visibility modifier grew four
> extra characters.  Perhaps we can come up with a keyword that is more
> succint.
>
> However, that is no reason to take away features from working codebases.
> A scoped access modifier is perhaps my favorite feature in Swift 3.  Let’s
> not throw stuff away because it adds extra characters to one programming
> style.
>
> Finally, SE-0025 establishes clear motivation for the scoped access
> modifier:
>
> > Currently, the only reliable way to hide implementation details of a
> class is to put the code in a separate file and mark it as private. This is
> not ideal for the following reasons:
>
> > It is not clear whether the 

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Pranshu Goyal via swift-evolution]

+1

On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution <
swift-evolution@swift.org> wrote:

> I would love to see this - and the sooner the better :)
>
> I think that the fact that Swift makes a type-level distinction between
> optional and non-optional makes it easier to trip yourself up when you work
> with Cocoa APIs that use pseudo-optionality, compared to when you work with
> ObjC. In ObjC you are aware 100% of the time that optionality is always
> represented in some way or another and that you have to expected
> inconsistency in the representation of optionality. So you keep this in
> mind and look out for it. But in Swift it’s easy to slide into the
> assumption that all APIs which return something that’s technically optional
> do indeed represent this as an optional type rather than some special
> integer value, float value or singleton object.
>
>
> Regards,
>
> Dietmar Planitzer
>
> > On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The feature in this case I would claim is independent of the adopters.
> Personally I think this would be a useful feature to allow for better
> exposition into swift but also more robust objective-c APIs.
> >
> > Something to consider here is that not all NSUIntegers can be
> NSNotFound, sometimes the return value is 0. It would be interesting to
> consider that _Nullable would be parameterized via a constant expression.
> This is a straw man refinement here (the exact spelling would be something
> we would have to audit the way it is implemented and likely use macros to
> compose the right nullability concepts)
> >
> > Lets take for example this API:
> >
> > + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream
> *)stream format:(NSPropertyListFormat)format 
> options:(NSPropertyListWriteOptions)opt
> error:(out NSError **)error;
> >
> > The return value here would be 0 if an error occurs. So the nullability
> value would be 0.
> >
> > + (nullable(0) NSInteger)writePropertyList:(id)plist
> toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format
> options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
> >
> > But other APIs like you indicated:
> >
> > - (NSUInteger)indexOfObject:(ObjectType)anObject;
> >
> > Could be converted to:
> >
> > - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
> >
> > Which would immediately be an indication to the reader what the “null”
> value would be represented as. Of course your concept of type aliases might
> be a decent way to group concepts together but if lets say there was an
> index type for NSArray; obviously you might want a index return value to be
> nullable but it would be a bit confusing to take a nullable parameter into
> certain APIs.
> >
> > Given a concept of NSArrayIndex as you suggested (that being nullable)
> would have the problem that
> >
> > - (ObjectType)objectAtIndex:(NSUInteger)index;
> >
> > Would either incorrectly indicate it would be nullable or it would have
> a different type.
> >
> > There would be other cases where structural types might need a nullable
> placeholder value, e.g. NSRange with a location of NSNotFound and a length
> of 0 (however that strictly isn’t correct since it is just the location
> that indicates null-ness.. but that is probably more of an implementation
> detail and should probably be corrected imho).
> >
> > There could also be cases where an API returns either an object of a
> specific type or NSNull as a placeholder. This would be nice to be able to
> express as a nullable type especially in generics. For example:
> `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express
> `Array` which cannot be expressed currently.
> >
> > Overall I think this could really reduce some of the overlays for all
> the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C
> APIs, offer more accurate bridged representations, and generally give API
> authors an opportunity to more correctly represent what should be exposed
> in Swift without needing to write overlays that could easily have poor
> interaction with things like subclassing or delegation.
> >
> > As a side note: I am not certain if the parameterization of nullability
> annotations would even be possible in the current compiler implementations
> or if it would be easier to use an attribute instead (that would be left to
> implementation detail).
> >
> > I would guess that if this feature would be available it would take a
> combined effort from all API maintainers to annotate their return values
> and any un-annotated shouldn’t be exposed as a IOU since they have non nil
> values already. Furthermore the timeframe to do so would probably be
> independent of the implementation of this type of feature.
> >
> > Those caveats aside - I think it would be a fantastic tool in the
> toolbox!
> >
> >> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <
> 

Re: [swift-evolution] The lack of namespaces is leading people astray

[Pranshu Goyal via swift-evolution]

+1

On 31 January 2017 at 11:32, Russ Bishop via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The lack of namespaces is making people create all kinds of "design
> patterns".
>
>
> What do you think?
>
>
> I’ve used languages with namespaces for many years. I don’t find
> multi-level namespaces to be much of an improvement over a single-level
> namespace in most cases. On the contrary, I find it much simpler to avoid
> hunting around importing a hundred namespaces. This is what you end up with:
>
> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Runtime.Serialization;
> using System.ServiceModel;
> using System.ServiceModel.Web;
> using System.Text;
> using System.Data;
> using System.Data.SqlClient;
> using System.Web;
> using System.Net;
> using System.Net.HttpClient;
>
>
>
> The only thing we really need in Swift is the ability to have a Private
> submodule, especially for mixed-mode frameworks.
>
>
> Russ
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Pranshu Goyal via swift-evolution]

What about `reducing(x, combine: {...})`

On 18 January 2017 at 07:47, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
>
> On Tue, Jan 17, 2017 at 7:46 PM, Sean Heber  wrote:
>
>> `reuse`
>>
>> Then we just need an excuse for a function named ‘recycle’...
>>
>> l8r
>> Sean
>>
>>
>> > On Jan 17, 2017, at 7:36 PM, T.J. Usiyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > `reduceInout`
>> >
>> > On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > Agree. The functional style should keep the functional name.
>> >
>> > On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >>
>> >>> On 17 Jan 2017, at 23:09, Karl Wagner 
>> wrote:
>> >>>
>> >>>
>>  On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> 
>>  Hi,
>> 
>>  How does everyone feel about adding a second version of `reduce` to
>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
>> functionals algorithms, but have the benefits of inout (mutation within the
>> function, and hopefully some copy eliminations).
>> 
>>  IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
>> ever since, because it can really improve readability (the possible
>> performance gain is nice, too).
>> 
>>  Here's `reduce` with an `inout` parameter, including a sample:
>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>> 
>>  --
>>  Chris Eidhof
>>  ___
>>  swift-evolution mailing list
>>  swift-evolution@swift.org
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>
>> >>> +1
>> >>>
>> >>> I would even argue for it to be the default.
>> >>
>> >> I mean, assuming having two “reduce”s would stress the typechecker, as
>> Joe suggested it might, I would say “inout” makes sense to be the default
>> and the other one can find itself a new name.
>> >
>> > IIRC, the "reduce" name comes from functional programming... should the
>> functional style keep the functional name?
>> >
>> > - Dave Sweeris
>> > ___
>> > 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
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Fixing raw enum types

[Pranshu Goyal via swift-evolution]

Definitely a +1, this clarifies intent, but enums are used a lot in swift
code, and considering this is a source breaking change I'm not sure if many
users of swift are going to be positive about this.

On 17 January 2017 at 02:32, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> Or perhaps paint the bikeshed
>
> enum Something<(Int32, Int32)> { … }
>
> -DW
>
> On Jan 16, 2017, at 11:51 AM, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This idea by Karl made me branch off a new thread.
>
> 2017-01-16 21:28 GMT+03:00 Karl Wagner :
>
>
> It would be helpful for synthesised RawRep conformance. The
>> inheritance-like syntax we have now is awful - it makes people think that
>> RawRepresentable is some kind of magic protocol that will allow special
>> compiler jango to happen.
>>
>> You could see why they think that. This looks very much like the enum is
>> going to *be* an Int32:
>>
>> enum Something: Int32 {
>> case oneThing = 36
>> case anotherThing = 42
>> }
>>
>> This is also one of the icky parts to allowing tuples of integer/string
>> literals (something people ask for quite a lot). It would look like you’re
>> deriving your enum from a non-nominal type:
>>
>> enum Something: (Int32, Int32) {
>> case oneThing = (3, 12)
>> case anotherThing = (5, 9)
>> }
>>
>>
>
> Even if Swift gains newtype, it’s not that case. The enum does not gain
> methods or behavior of the specified type. It’s just a shorthand, hinting
> the compiler to provide correct RawRepresentable conformance.
>
> I suggest to invent a new syntax for this type hinting for
> RawRepresentable. For example, it can be an annotation:
>
> @raw(Int32) enum Something {
> // ...
> }
>
> Or a contextual keyword:
>
> enum Something : raw(Int32) {
> // ...
> }
>
> Perhaps, he most uniform and explicit of syntaxes:
>
> enum Something : RawRepresentable {
> case oneThing = 36
> case anotherThing = 42
> }
>
> enum AnotherThing : RawRepresentable {
> typealias RawValue = Int32
> case oneThing
> case anotherThing
> }
>
> ​
> ___
> 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
>
>


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