Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

[Elviro Rocca via swift-evolution]

Hi Chris, thanks a lot for the answer, that's exactly what I wanted to read and 
it gives me hope for the language's future :)

- Elviro

> Il giorno 12 dic 2016, alle ore 06:46, Chris Lattner  ha 
> scritto:
> 
> On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution 
> > wrote:
>> Hi everyone, I read every post in the Higher-Kinded Types ( 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html
>>  
>> 
>>  ) thread from about a year ago, and I was wondering what's the status on 
>> the matter: I'm aware of the proposal draft ( 
>> https://github.com/typelift/swift/issues/1 
>>  ), but I'd like to know if the 
>> Swift team has reconsidered the possible relevance of HKT for Swift in the 
>> foreseeable future.
> 
> Hi Elviro,
> 
> HKT’s come up from time to time, so there is definitely interest, that said, 
> I can’t imagine that this will be a priority to get done in Swift 4.
> 
>> By reading the discussion I found that the main concern from the Swift team 
>> was about practical use cases that could be of interest for a huge chunk of 
>> Swift developers: I don't think that a language feature should be there only 
>> if affects the majority of users, because of course you always have users at 
>> many different levels of awareness and understanding, not to mention 
>> experience and background,
> 
> Right.  I’m personally not opposed to having advanced features in Swift when 
> they are highly motivated.  We only aim to make sure that they only 
> affect/benefit people who want to use them.  Advanced features that beginners 
> are forced to reckon with violate our goals to have a shallow learning curve. 
>  HKTs seem like they’d be fine in this regard.
> 
>> but I understand that, considering the time constraints in language 
>> development and proposals review, the focus should (initially) be on things 
>> that matter the most to the vast majority of developers.
> 
> Right, this is the principle reason I can’t imagine that HKTs will get 
> prioritized.  There are a *TON* of improvements that will have widespread 
> positive impact, and the Swift compiler team is very thinly spread.  We are 
> forced to pick and choose a few things that we think will have the biggest 
> impact on the entire Swift community.
> 
> -Chris
> 

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

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

[Benjamin Spratling via swift-evolution]

-Ben

Sent from my iPhone.

> On Dec 11, 2016, at 11:43 PM, Brian Gesiak  wrote:

> Maybe your goal is to ensure that other programmers don't accidentally change 
> the accessibility levels. Again, I think because they're straightforward, I 
> don't think there's much danger there.
> 
> To me, tests for accessibility would be redundant. It would be like adding a 
> test to verify that my struct 'Foo' has a member named 'bar'. If I ever 
> decided to rename 'Foo.bar', I would have to update the test. But I would 
> never "accidentally" rename 'Foo.bar' -- if I changed the name, it's because 
> I modified the code for that purpose. A test adds overhead, but no benefit.
> 
> I feel the same about the 'mutating', 'weak', 'unowned', and 'final'.
> 
> It's definitely subjective, though. You might feel that the tests I describe 
> above are valuable, and you're entitled to that opinion.


I have been in some situations recently in which encapsulation was untestable, 
and on a team with >10 developers and no automated test to catch that change, 
there were issues.  In the end we shipped knowing there was a bug, because 15 
weeks of work had been based on it, and it would have required a redesign to 
fix.

If I need a test that there is a property named 'bar', I can write a test which 
accesses the member, and even specify a required type and explicitly test 
whether the property does or does not conform to the protocol.  Even if it's 
private, I can use a Mirror to extract its value.

My motivation is: I got tired of hearing "if you did it right, it would have 
worked", which I now view as an excuse for lack of good design (in most cases). 
 For the past several months, I have been investigating design patterns which 
prevent developers from making common mistakes, and how to write tests to catch 
changes to those patterns.  I can't even count the number of unfathomable bugs 
I've fixed merely by improving the design.  Swift is notable in that its 
compiler can enforce many of these patterns, so I prefer it over Obj-C.  Proper 
encapsulation is one such technique, and it turns out it's untestable.

Thanks for your suggestion about researching how other languages do this.  I'll 
see what I can do, though the only experience I have in any of the ones you 
mentioned is pre-11 C++, so if anyone else knows how such checks are done, I'd 
greatly appreciate hearing from you.

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

Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

[Chris Lattner via swift-evolution]

On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution 
 wrote:
> Hi everyone, I read every post in the Higher-Kinded Types ( 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html
>  
> 
>  ) thread from about a year ago, and I was wondering what's the status on the 
> matter: I'm aware of the proposal draft ( 
> https://github.com/typelift/swift/issues/1 
>  ), but I'd like to know if the 
> Swift team has reconsidered the possible relevance of HKT for Swift in the 
> foreseeable future.

Hi Elviro,

HKT’s come up from time to time, so there is definitely interest, that said, I 
can’t imagine that this will be a priority to get done in Swift 4.

> By reading the discussion I found that the main concern from the Swift team 
> was about practical use cases that could be of interest for a huge chunk of 
> Swift developers: I don't think that a language feature should be there only 
> if affects the majority of users, because of course you always have users at 
> many different levels of awareness and understanding, not to mention 
> experience and background,

Right.  I’m personally not opposed to having advanced features in Swift when 
they are highly motivated.  We only aim to make sure that they only 
affect/benefit people who want to use them.  Advanced features that beginners 
are forced to reckon with violate our goals to have a shallow learning curve.  
HKTs seem like they’d be fine in this regard.

> but I understand that, considering the time constraints in language 
> development and proposals review, the focus should (initially) be on things 
> that matter the most to the vast majority of developers.

Right, this is the principle reason I can’t imagine that HKTs will get 
prioritized.  There are a *TON* of improvements that will have widespread 
positive impact, and the Swift compiler team is very thinly spread.  We are 
forced to pick and choose a few things that we think will have the biggest 
impact on the entire Swift community.

-Chris

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

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

[Brian Gesiak via swift-evolution]

Hi Benjamin,

I think your proposal is interesting, and you're certainly right: XCTest
has no way to test accessibility levels, or the other attributes you
mention. However, I wonder, what do you hope to achieve by adding an
automated test for accessibility levels?

Maybe your goal is to verify the accessibility level is what you think it
is. However, in my experience, accessibility levels are fairly
straightforward: if I specify a variable is 'public', it's public. If I
specify it to be 'fileprivate', it's private to the file. I could write an
automated test to verify the accessibility level, but the test would
provide me with very little value.

Maybe your goal is to ensure that other programmers don't accidentally
change the accessibility levels. Again, I think because they're
straightforward, I don't think there's much danger there.

To me, tests for accessibility would be redundant. It would be like adding
a test to verify that my struct 'Foo' has a member named 'bar'. If I ever
decided to rename 'Foo.bar', I would have to update the test. But I would
never "accidentally" rename 'Foo.bar' -- if I changed the name, it's
because I modified the code for that purpose. A test adds overhead, but no
benefit.

I feel the same about the 'mutating', 'weak', 'unowned', and 'final'.

It's definitely subjective, though. You might feel that the tests I
describe above are valuable, and you're entitled to that opinion.

If you'd still like to pursue this idea, I think your Swift Evolution
proposal would benefit from research on how other languages and testing
frameworks approach this problem. How do C++ programmers test whether an
attribute is private? How do Java developers test that a class is final?
What about Rust or Go?

- Brian Gesiak


On Mon, Dec 12, 2016 at 12:10 AM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> It bugs me as well that we can not test private components using XCTest.
> Objective-c never had this problem since privacy doesn't exist. I would
> like to see a version of XCTest that allows us to test every component.
>
>
>
> On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Howdy,
>> I’d like to see how much interest there is for adding these to
>> the XCTest module.  If I have missed some pro or con, or missed a technical
>> point, your feedback is welcome before I go to the lengths to draw up a
>> formal proposal.
>>
>>
>> There are several features of Swift which cannot be effectively
>> automated-tested.
>> For instance, when a type or one of its members is private or file
>> private, an outside test suite cannot access it, and the information that
>> the type is private is not included in a Mirror.  There are similar
>> concerns for testability with internal, and public access levels.  Tests
>> can be written ensuring these access levels are >= some level, but not ==
>> or < some level.  In other words the very usefulness of these features
>> cannot be tested.
>>
>> Other attributes to be tested in this way are:
>>
>> - Mutability of a member.  No automated test can be written which
>> verifies that a function cannot be called on a let struct, or that a
>> property cannot be set at a specific access level.
>>
>> - That a stored property is weak or unowned.
>>
>> - That a class or class member is “final”
>>
>> These are concepts which need to be unit-tested to ensure good design is
>> not broken, but do not need to be included in a release build, so including
>> them in the XCTest framework seems like an appropriate destination.
>> Moreover, the information for all of these features exists in the
>> .swiftmodule files, which are included in test builds, but sometimes
>> stripped for release.
>>
>> Examples:
>> Since these features inherently have to do with testing features which
>> cannot be stated in compiled code, I recommend specifying names with
>> Strings.  Here are some examples of what I would like to write in my test
>> code:
>>
>> XCTAssertEqual( Module(named:”SingMusicLayout”
>> )?.type(named:”NoteSetter”)?.property(named:”session”)?.accessLevel,
>> .private)
>>
>> XCTAssertEqual( Module(named:”SingMusicLayout”
>> )?.type(named:”ScaleLayout”)?.method(named:”baselineOffset(
>> for:PitchInterval)->CGFloat”)?.mutable, false)
>>
>>
>> Alternatives:
>> 1.  Building an independent .swiftmodule parser in a single Swift
>> module, which can be included in test builds.
>> + Can be distributed independently from Swift sources,
>> requiring 0 buy-in from Swift community
>> + requires a single additional module for the test.
>> - Depends on ever-changing binary interface.
>> : Intractable, not DRY
>>
>> 2.  Use existing sourcekitd.
>> + harnesses changes in the compiler’s source code with
>> SourceKit
>> - cannot be run in a test suite without extensive work by
>> user to configure bundles 

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

[Derrick Ho via swift-evolution]

It bugs me as well that we can not test private components using XCTest.
Objective-c never had this problem since privacy doesn't exist. I would
like to see a version of XCTest that allows us to test every component.


On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Howdy,
> I’d like to see how much interest there is for adding these to the
> XCTest module.  If I have missed some pro or con, or missed a technical
> point, your feedback is welcome before I go to the lengths to draw up a
> formal proposal.
>
>
> There are several features of Swift which cannot be effectively
> automated-tested.
> For instance, when a type or one of its members is private or file
> private, an outside test suite cannot access it, and the information that
> the type is private is not included in a Mirror.  There are similar
> concerns for testability with internal, and public access levels.  Tests
> can be written ensuring these access levels are >= some level, but not ==
> or < some level.  In other words the very usefulness of these features
> cannot be tested.
>
> Other attributes to be tested in this way are:
>
> - Mutability of a member.  No automated test can be written which verifies
> that a function cannot be called on a let struct, or that a property cannot
> be set at a specific access level.
>
> - That a stored property is weak or unowned.
>
> - That a class or class member is “final”
>
> These are concepts which need to be unit-tested to ensure good design is
> not broken, but do not need to be included in a release build, so including
> them in the XCTest framework seems like an appropriate destination.
> Moreover, the information for all of these features exists in the
> .swiftmodule files, which are included in test builds, but sometimes
> stripped for release.
>
> Examples:
> Since these features inherently have to do with testing features which
> cannot be stated in compiled code, I recommend specifying names with
> Strings.  Here are some examples of what I would like to write in my test
> code:
>
> XCTAssertEqual(
> Module(named:”SingMusicLayout”)?.type(named:”NoteSetter”)?.property(named:”session”)?.accessLevel,
> .private)
>
> XCTAssertEqual(
> Module(named:”SingMusicLayout”)?.type(named:”ScaleLayout”)?.method(named:”baselineOffset(for:PitchInterval)->CGFloat”)?.mutable,
> false)
>
>
> Alternatives:
> 1.  Building an independent .swiftmodule parser in a single Swift
> module, which can be included in test builds.
> + Can be distributed independently from Swift sources,
> requiring 0 buy-in from Swift community
> + requires a single additional module for the test.
> - Depends on ever-changing binary interface.
> : Intractable, not DRY
>
> 2.  Use existing sourcekitd.
> + harnesses changes in the compiler’s source code with
> SourceKit
> - cannot be run in a test suite without extensive work by
> user to configure bundles explicitly.
> Exceptionally poor user experience
> : sourcekitd XPC architecture only works on macOS
>
> 3.  Use a standalone tool for tests
> + harnesses changes in the compiler’s source code with
> SourceKit
> + no installation in user’s source code necessary
> : cannot be effectively run by SPM test infrastructure
>
> ___
> 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] adding automated-testing of uncompilable features in XCTest

[Benjamin Spratling via swift-evolution]

Howdy,
I’d like to see how much interest there is for adding these to the 
XCTest module.  If I have missed some pro or con, or missed a technical point, 
your feedback is welcome before I go to the lengths to draw up a formal 
proposal.


There are several features of Swift which cannot be effectively 
automated-tested.
For instance, when a type or one of its members is private or file private, an 
outside test suite cannot access it, and the information that the type is 
private is not included in a Mirror.  There are similar concerns for 
testability with internal, and public access levels.  Tests can be written 
ensuring these access levels are >= some level, but not == or < some level.  In 
other words the very usefulness of these features cannot be tested.

Other attributes to be tested in this way are:

- Mutability of a member.  No automated test can be written which verifies that 
a function cannot be called on a let struct, or that a property cannot be set 
at a specific access level.

- That a stored property is weak or unowned.

- That a class or class member is “final”

These are concepts which need to be unit-tested to ensure good design is not 
broken, but do not need to be included in a release build, so including them in 
the XCTest framework seems like an appropriate destination.
Moreover, the information for all of these features exists in the .swiftmodule 
files, which are included in test builds, but sometimes stripped for release.

Examples:
Since these features inherently have to do with testing features which cannot 
be stated in compiled code, I recommend specifying names with Strings.  Here 
are some examples of what I would like to write in my test code:

XCTAssertEqual( 
Module(named:”SingMusicLayout”)?.type(named:”NoteSetter”)?.property(named:”session”)?.accessLevel,
 .private)

XCTAssertEqual( 
Module(named:”SingMusicLayout”)?.type(named:”ScaleLayout”)?.method(named:”baselineOffset(for:PitchInterval)->CGFloat”)?.mutable,
 false)


Alternatives:
1.  Building an independent .swiftmodule parser in a single Swift module, 
which can be included in test builds.
+ Can be distributed independently from Swift sources, 
requiring 0 buy-in from Swift community
+ requires a single additional module for the test.
- Depends on ever-changing binary interface.
: Intractable, not DRY

2.  Use existing sourcekitd.
+ harnesses changes in the compiler’s source code with SourceKit
- cannot be run in a test suite without extensive work by user 
to configure bundles explicitly.
Exceptionally poor user experience
: sourcekitd XPC architecture only works on macOS

3.  Use a standalone tool for tests
+ harnesses changes in the compiler’s source code with SourceKit
+ no installation in user’s source code necessary
: cannot be effectively run by SPM test infrastructure

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

Re: [swift-evolution] [Discussion] Generic protocols

[Anton Zhilin via swift-evolution]

2016-12-10 14:57 GMT+03:00 Adrian Zubarev :

I’m fine with adding features step by step. ;)
>
> There is no need for an explicit type alias in your
>
> extension MyStruct : Constructible { … }
>
> Because Value is already constrained by String.
>
That was my proposed syntax for inline conversion of associated-types
protocols to generics. In this case, implicit or explicit, this typealias
would appear in MyStruct.

In my typealias examples I mixed *1.* and *4.* together.
>
> protocol GenericFoo : Foo where Value == T { /* nothing here */ }
>
> typealias GenericFoo = Foo where Value == T
>
> I see that the latter cannot produce an actual new protocol, because it’s
> more like a macro and cannot be used multiple times for conformances.
>
> struct D : GenericFoo, GenericFoo {}
>
> // vs.
> struct D : Foo where Value == Int, /* cannot add the second macro for String 
> */ {}
>
> And that is probably why we need real parametrized protocols.
>
That was not an unsolvable problem, but I guess, parametrized protocols is
the first feature to consider.

Questions about *1.*:
>
>- Does it affect ABI or is it needed to simplify the stdlib somehow?
>- Is it something for the current phase?
>
> I found that the only protocol family that looks like it could be replaced
by a generic protocol, is ExpressibleBy* protocols.
But on a closer look, each of them has its own nuances, which prevents us
from using a single LiteralConvertible instead.

So I guess, no existing ABI would need changes, and stdlib is not affected.
So probably it’s not for current phase?
I really wish I’m wrong here.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

I cannot reply directly to this message 
https://www.mail-archive.com/swift-evolution@swift.org/msg19099.html so I will 
reply here instead.
I am suggesting that both behaviours should be allowed to co-exists (which is 
already the case, just there is this one exception.)
No matter the implications of access level I see this as a matter of 
consistency as well, at the end of the day an operator is a function with some 
sugar and a special name.
So while I am able to declare a static function as part of a struct/class like 
so:
```
public struct NonEmptyArray {
    private var elements: Array
    private init(array: [Element]) {        self.elements = array    }
        public static func cons(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {        return NonEmptyArray(array: rhs + 
[lhs])    }```
And "fake" the operator by calling the cons function
```//Overload 1public func •|(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {    return NonEmptyArray.cons(array: rhs + [lhs])}```
It seems to me that the only reason we're currently not allowed to declare the 
operator directly inside NonEmptyArray is because is begins with some special 
UTF8 character.
If you want to define your overload as free form functions or as static methods 
on structs/classes it's really up to you.
/Tommaso 

On Sunday, December 11, 2016 1:57 AM, Tommaso Piazza via swift-evolution 
 wrote:
 

 Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md



___
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] Higher Kinded Types (Monads, Functors, etc.)

[Elviro Rocca via swift-evolution]

Hi everyone, I read every post in the Higher-Kinded Types ( 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html
 

 ) thread from about a year ago, and I was wondering what's the status on the 
matter: I'm aware of the proposal draft ( 
https://github.com/typelift/swift/issues/1 
 ), but I'd like to know if the 
Swift team has reconsidered the possible relevance of HKT for Swift in the 
foreseeable future.

By reading the discussion I found that the main concern from the Swift team was 
about practical use cases that could be of interest for a huge chunk of Swift 
developers: I don't think that a language feature should be there only if 
affects the majority of users, because of course you always have users at many 
different levels of awareness and understanding, not to mention experience and 
background, but I understand that, considering the time constraints in language 
development and proposals review, the focus should (initially) be on things 
that matter the most to the vast majority of developers.

But the idea of opposing a proposal because it's "hard to understand" (to some 
people, with different background) is baffling to me: there could be NO 
evolution whatsoever if everyone's only focus was on what feels familiar. But I 
don't want to talk about this: I just want to mention that if someone argues 
that they're not understanding a construct even if they consider themselves 
smart and experienced, that's their problem (maybe they're simply non 
experienced in that particular field), not a problem of the construct itself. 
And the fact that most things are mappable is not something functional 
programmers "believe": there's a huge corpus of research in the field of 
abstract mathematics that confirms this intuition. But anyway, let's move on.

I'd like to mention something that I consider a practical use case for the need 
of being able to express something like mappables and flatMappables in a 
abstract way: what's usually referred to as "monad transformers". I know that 
it's another concept that can be hard to grasp if you're not used to work with 
monads, but bear with me. Also, not sure about the etiquette here: it's an old 
discussion, but I wanted to offer my two cents.

Many functional programming techniques try to achieve true composability of 
code by decomposing logic in generic classes, that express a particular piece 
of that logic: the "Result" type  ( https://github.com/antitypical/Result 
 ) is a classic case (the same concept 
is similarly implemented by Swift throwable functions, but in a less composable 
way). There are many more types that do this, for example the Deferred type ( 
https://github.com/bignerdranch/Deferred 
 ) was also mentioned in the 
discussion. Another type that I use a lot is the Writer type ( 
https://en.wikipedia.org/wiki/Monad_(functional_programming)#Writer_monad 
 ) 
that lets me accumulate an auxiliary result while executing an algorithm ( for 
example, generating an index path while traversing a tree ). And the Optional 
type is already in Swift. But while these types are useful by themselves, they 
become even more powerful when combined: for example, Deferred + Result is 
basically a Future, that is, an asynchronous computation that can fail. Even 
more interesting is a Deferred + Writer + Result (I going to refer to it as 
"DefWriRes"), something that I currently use while developing my HTTP clients, 
because I can accumulate information about request and response in a clean, 
composable way: unfortunately, mapping and flatMapping breaks when combining 
these types, because mapping a DefWriRes will require a function working on 
Writer, while I really just work on the type wrapped by the internal Result. 
Monad transformers work that way: they allow you to "go deeper" in combined 
monads. Now, the interesting thing is that to map a DefWriRes we only need to 
now that Deferred, Writer and Result are mappable, but without this abstraction 
I'm forced to copy and paste hundreds of lines of code (for every possible 
combination) where the only thing that changes is the type definition, because 
the method calls are just maps.

The case is similar for flatMap, so I need to call "flatMap" on something 
that's flatMappable, with the difference that I need to be able to unwrap the 
value in the Result (so I need to know how Result works, it's not just 
mapping), and I need to be able to create a "empty" Writer and Deferred (that's 
already achievable by the type system). But the case is similar, the only 
difference is that I need a specific "ResultTransformer" (I actually 
implemented this via protocols and constrained extensions, but the 

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

Thanks for the suggestion,
I have updated the proposal with the error and with the notes on `fileprivate` 
-> `private`
/Tommaso 

On Sunday, December 11, 2016 5:55 AM, Derrick Ho  
wrote:
 

 You may want to add the specific error to your proposal.  
error: member operator '•|' must have at least one argument of type 
'NonEmptyArray'        public static func •|(lhs: Element, 
rhs: [Element]) -> NonEmptyArray
On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho  wrote:

I placed he code you wrote in the proposal in playgrounds and it works 
perfectly.  (reproduced below). Overloading operators used to only happen 
globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray 
{
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs: 
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}
However, as you have detailed when you place those overloads inside the 
struct/class, it does not work.  Actually I get an error that says that at 
least ONE of the arguments needs to be the same type.  In this case one of them 
needs to be NonEmptyArray. It is clearly not a bug, but rather a swift 
rule.
My recommendation is to just keep those overloads as global.  Is there a 
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
 wrote:
Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md


That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.
- 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

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tino Heth via swift-evolution]

imho the current behaviour is fine.

I'll leave aside infix-operators, because with pre/postfix, the situation is 
simpler:
It seems slightly confusing to me to declare such an operator somewhere else 
but at the type it works on.

Afair the ability to declare an infix operator in a type definition came with 
the redefinition of access levels, possibly motivated by the ability to use 
private properties.
This might as well be the reason not to enforce that the operator has to be 
defined in the type of the first operand (which I'd consider to be preferable 
whenever possible).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

Hello Derrick,
I did not think of this as a bug but rather as an intentional limitation that 
to me seems a little odd.
Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when 
declared as static function on NonEmptyArray they work fine. However Overload 1 
just mentions NonEmptyArray in the return type. I propose that it should also 
be allowed as a static function on NonEmptyArray.
As for the why it should be allowed my motivation is that all overloads that 
mention NonEmptyArray in their type signature should be allowed to be declared 
in the same namespace.Or one could argue that no overloads should be declarable 
inside NonEmptyArray. 
However this comes at a price.
Note that because overload 1 in the current situation must be left out of 
NonEmptyArray, the accessor modifier for properties and function in 
NonEmptyArray is fileprivate.With the change I propose this is no longer the 
case and the modifier is just private.
/Tommaso
On Sunday, December 11, 2016 5:49 AM, Derrick Ho  
wrote:
 

 I placed he code you wrote in the proposal in playgrounds and it works 
perfectly.  (reproduced below). Overloading operators used to only happen 
globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray 
{
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs: 
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}
However, as you have detailed when you place those overloads inside the 
struct/class, it does not work.  Actually I get an error that says that at 
least ONE of the arguments needs to be the same type.  In this case one of them 
needs to be NonEmptyArray. It is clearly not a bug, but rather a swift 
rule.
My recommendation is to just keep those overloads as global.  Is there a 
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
 wrote:
Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md


That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.
- 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