> On Jul 15, 2016, at 10:52 PM, Chris Lattner wrote:
>
> * What is your evaluation of the proposal?
I agree with the core team that closed by default for classes is the right move.
I also think that it makes sense for methods to be closed by default.
**However**, I am seriously concerned
I'm building an document-based app, and I'm having a problem regarding to Set.
What I hope to achieve is to have a Set of unique objects by their references.
For example, I might put in two rectangles with the same height and width
(which makes them equal, but they are still different instances)
Because extensions are not types.
They are still bound to the type you extend. IMHO they should obey the access
rules types follow, but we don’t want to debate this anymore. It won’t ever
happen.
I don’t think that attacking people for their whining and laziness is very
constructive. Please res
> What I hope to achieve is to have a Set of unique objects by their
> references. For example, I might put in two rectangles with the same height
> and width (which makes them equal, but they are still different instances).
I guess this is not the best place for such problems, but did you alre
> 在 2016年7月17日，17:44，Tino Heth <2...@gmx.de> 写道：
>
>
>> What I hope to achieve is to have a Set of unique objects by their
>> references. For example, I might put in two rectangles with the same height
>> and width (which makes them equal, but they are still different instances).
> I guess th
Hello, community.
As I understood from documentation the only way to iterate multidimensional
array or a dictionary (with for loop) is this:
let multidimensionalDictionary = ["a":["b": "c"], "b":["c": "d"], "c":
["d": "e"]]
for (key, value) in multidimensionalDictionary {
for (nestedKey, nest
I naturally assumed that "public" and "open" would be two separate concepts, as
it has been expressed that orthogonality* is favored.
But actually reading the proposal, it says:
"open is invalid on declarations that are not also public", which imho not only
is an unnecessary mingling of the two c
I naturally assumed that "public" and "open" would be two separate concepts, as
it has been expressed that orthogonality* is favored.
But actually reading the proposal, it says:
"open is invalid on declarations that are not also public", which imho not only
is an unnecessary mingling of the two c
Regards
(From mobile)
> On Jul 17, 2016, at 8:07 AM, Adrian Zubarev via swift-evolution
> wrote:
>
> My first draft had some mistakes related access modifier on extension but the
> final proposal does fully understands how they work and aims to eliminate
> default access modifier behavior.
That’s what this mailing list is for. To discuss everything with the community
and the core team behind Swift. If you don’t try, you won’t get anything. If
everyone would be afraid to tackle something that might go really wrong during
review, nothing will happen at all. We’ll end up with a langu
For those who are interested, this is the latest version of the proposal:
https://gist.github.com/DevAndArtist/1332e1458e0791f8f4b1649cbeb4fce5
Casting as written in this proposal works in theory, but I had some problems
implementing it, so it does work with protocols conformance
We also have s
> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution
> wrote:
> The second review of "SE-0117: Default classes to be non-subclassable
> publicly" begins now and runs through July 22. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/propo
> * What is your evaluation of the proposal?
I'm not in favor.
Briefly: I may soon propose an overload of `..<` like so:
func ..< (lhs: Bound?, rhs: Bound?) ->
IncompleteRange {…}
This operator is one which ought to lift its parameters to greater optionality.
I can only assume t
> * What is your evaluation of the proposal?
Another quick hit. The proposal says this:
>>> Until generics are more mature, the issue of Optional being conditionally
>>> Comparable can't be fully discussed/implemented, so it makes the most sense
>>> to remove these questionably-useful ope
> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution
> wrote:
>
> 1. Custom implementation of equals operator `==` for value types should be
> forbidden. Rationale: Why has it been added in the first place? For omitting
> some values from the equals test?
This limitation would
> Am 17.07.2016 um 15:11 schrieb Brent Royal-Gordon :
>
>> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution
>> wrote:
>>
>> 1. Custom implementation of equals operator `==` for value types should be
>> forbidden. Rationale: Why has it been added in the first place? For omitt
As an alternative to having `open` as a separate access level, we could
instead have it merely imply `public`: the canonical form would be `public
open`, but source code could just say `open`. Generated interfaces would always
say `public open`, so searching for `public` in those would wor
That's a good point. I will incorporate these into a revised draft. Only
two things will change:
```
public struct Foo {
// implicitly internal
func frobnicate1() { }
}
public extension Foo {
// currently implicitly public
//
// depending on which alternative is adopted,
// the proposa
I still don’t catch to point here. There is no implicit public there. It’s
explicit set by the default access modifier of extensions. It’s how they work
and how they should remain (at least as long the community want default access
modifier to exist on extensions). Disallowing setting public on
The proposal is that the access modifier for an extension will either be
removed entirely or remain as an upper bound, losing its function as a
default access modifier. The default access modifier rule permits public
methods to be written without `public func`; this is a proposal to remove
that fea
I think this use-case is too narrow for dedicated syntax in the standard
library.
However, it should be simple enough for you to write your own function,
let’s call it `unpack`, which produces a sequence that does what you want.
While you’re at it you could also try writing a `cross` function tha
I tackled it as an upper bound but highly rejected by the community. That’s
exactly what my proposal was all about. An upper boundary would be more
elegant, but I still see arguments ‘because it’s not a type’.
I could live without access modifiers on extensions in general.
The default access mo
I understand how it works.
By aligning access modifier rules inside extensions with those inside
types, all other modifiers would continue to work as it does now
(implicitly internal members would be limited by the upper bound). The only
change in this respect is removing the ability to have publi
> On 15 Jul 2016, at 20:14, Tino Heth <2...@gmx.de> wrote:
>
> The last post in this thread is nearly a week ago... did you already apply
> for review?
> It would be a pity if this topic isn't finished, and I think a reduced
> variant that merely replaces "values: Int…" with "@variadic _ values
On Sun, Jul 17, 2016 at 2:00 AM, 张国晔 via swift-evolution
wrote:
> I'm building an document-based app, and I'm having a problem regarding to Set.
>
> What I hope to achieve is to have a Set of unique objects by their references.
Try this:
public final class ReferenceEqualityBox : Hashable {
pub
> On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution
> wrote:
>
>> On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution
>> wrote:
>> My first draft had some mistakes related access modifier on extension but
>> the final proposal does fully understands how they work a
Is there a summary somewhere of the motivation for allowing methods to be
declared non-overridable within open classes?
I’m not asking about any particular syntax or default, just why you'd want this
facility at all. The proposal doesn’t mention this, and the discussion of the
initial version n
re: cross (nod to Dave Abrahams for the clean implementation)
/// 'Cartesian product' of two sequences
public func cartesianProduct(lhs:Left,
rhs:Right) -> [(Left.Iterator.Element, Right.Iterator.Element)] {
return lhs.flatMap { x in rhs.map { (x, $0) } }
}
On Sun, Jul 17, 2016 at 11:54 AM,
On Sun, Jul 17, 2016 at 1:42 PM, Jose Cheyo Jimenez
wrote:
>
>
> On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> My first draft had
I too would be interested in this info. Brent's numbers look daunting
indeed (nearly 2000 annotations for methods and properties in
corelibs-foundation alone). What use cases are supported by
sealed-but-not-final public methods in open classes?
On Sun, Jul 17, 2016 at 2:14 PM, Garth Snyder via sw
on Sun Jul 17 2016, Tino Heth wrote:
> I naturally assumed that "public" and "open" would be two separate
> concepts, as it has been expressed that orthogonality* is favored.
> But actually reading the proposal, it says:
> "open is invalid on declarations that are not also public", which imho
>
I think the discussion on this has run its course and it sounds like there’s
mixed feelings, but it’s mostly a matter of opinion between consistency and
“ugliness”. As I understand it, the “socialization” process isn’t meant to
reach consensus, but to hone the proposal (or abandon it if the fee
> On Jul 17, 2016, at 7:29 AM, Karl Wagner wrote:
>
> Open and public are orthogonal concepts, just like final and public are today.
Are they? Given that "open" *means* "subclassable/overridable in public scope",
what would it mean for something to be open, but not public? `final` *is*
orthogo
I reviewed the original proposal, and this revised text is a much better step
forwards; I still think there are a few changes I’d like to see before fully
getting behind it.
Consider this a +0.5.
I like the use of the additional `open` keyword on top of `public`, it has a
nice symmetry to the
Your initial rationale no longer makes sense with your suggested solution. If
the dumb comparison returns false, people can still introduce side effects in
the comparison method, except that now it's even harder to find out because all
of my equality tests have been rewritten as "memcmp(a, b) ||
> 在 2016年7月18日，02:08，Dmitri Gribenko 写道：
>
> On Sun, Jul 17, 2016 at 2:00 AM, 张国晔 via swift-evolution
> wrote:
>> I'm building an document-based app, and I'm having a problem regarding to
>> Set.
>>
>> What I hope to achieve is to have a Set of unique objects by their
>> references.
>
> Try
>
> * What is your evaluation of the proposal?
>
+1. Agree the comparison can be surprising, and it also confuses some
people trying to understand optionals, apparently; I once couldn't convince
someone how it worked until shortly afterwards for another issue @jckarter
phrased it "Optional
Regards
(From mobile)
> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution
> wrote:
>
> Is there a summary somewhere of the motivation for allowing methods to be
> declared non-overridable within open classes?
>
> I’m not asking about any particular syntax or default, just why you
so, you want to propose default == operator but not forbidding all peoples
to custom == operator?
Why don't just adding the following function to std library?
public func == (lhs: T, rhs: T) -> Bool {
var lhs = lhs
var rhs = rhs
return memcmp(&lhs, &rhs, sizeof(T.self)) == 0
}
T
39 matches
Mail list logo
