Beautiful, +1
Rien
> On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution
> wrote:
>
> Introduction
>
> This proposal addresses significant unexpected performance gaps when using
> dictionaries. It introduces type-specific collections for a Dictionary
> instance's keys and values propert
on Tue Oct 11 2016, Slava Pestov wrote:
> I could if there’s interest. Since we intend on maintaining source
> compatibility, it will not result in a simpler implementation, though,
> since we’ll need to keep the old code path around for Swift 3
> mode. Still worth it?
IIUC it especially makes
I’d give a +1 for the suggestion of Braeden.
Mateusz, you lost me with “store some extra data”.
Does that mean something extra besides the code that Braeden suggested?
Rien.
> On 12 Oct 2016, at 00:13, Mateusz Malczak via swift-evolution
> wrote:
>
> That's exactly what this proposal is about
on Tue Oct 11 2016, Károly Lőrentey wrote:
> +1
>
> ManagedBuffer has been really useful a couple of times, but I never
> found a use for ManagedBufferPointer. I can’t even say I’m entirely
> sure what need it was originally designed to fulfill.
The real need is/was to be able to do the same ki
> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution
> wrote:
>
> Implementation idea No. 4:
>
> The basic concept is that the dynamic linker would fixup the offsets as well
> as relocating the addersses, allowing the size of objects (and maybe
> structs?) to change at link-time. Th
+1. Haven't hit this issue personally, but I agree it's important and the
proposed solution seems like the right fix.
On Tue, Oct 11, 2016 at 2:28 PM, Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:
> Introduction
>
> This proposal addresses significant unexpected performance ga
On Tue, Oct 11, 2016 at 8:21 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
> On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> enum RectSize
> {
>let height:Int
>let width:Int
>case small(width: 30,
Painful +1.
I use the first one a whole lot in a project and it is going to get ugly.
That said… I can see how it is tricky in a way that doesn't really pay off
for most people. Removing the first feature might even be necessary for
what I hope will ease the ugly. I don't see "Default generic argu
+1. I don't use this feature at all and (by extension) don't think there are
many situations where it's useful.
~Robert Widmann
2016/10/11 18:03、Slava Pestov via swift-evolution
のメッセージ:
> I could if there’s interest. Since we intend on maintaining source
> compatibility, it will not result
> On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution
> wrote:
>
> enum RectSize
> {
>let height:Int
>let width:Int
>case small(width: 30, height: 30)
>case medium(width: 60, height: 60)
>case large(width: 120, height: 120)
> }
I like the concept, but this doesn
Interestingly, if all the stored properties defined in extensions could be
determined at link-time, the size/layout of the side-table could include
them directly, removing the need for further indirection. The offsets would
still need to be fixed up, which would add some complexity to the
implement
> On Oct 11, 2016, at 4:48 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> Additional info for your reference:
>
> * Chris Lattner's original email on additional goals and non-goals for Swift
> 4:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>
>
Wow, that's a very interesting post. Sounds a lot simpler to implement than
my idea about fixing up offsets in the linker and preserves binary
compatability just the same.
I got some complaints when I first started talking about this that the
runtime would have to track extra pointers and performa
Additional info for your reference:
* Chris Lattner's original email on additional goals and non-goals for
Swift 4:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
* Chris Lattner's speculation that Swift 3.x will be time-based: whatever's
accepted for Swift 4 a
As far as I know, there will be, but I'm not aware of new evolution
proposals being accepted specifically for those releases. Perhaps core team
folks can chime in.
On Tue, Oct 11, 2016 at 18:31 Jay Abbott wrote:
> So does that mean there's not going to be any 3.x versions between 3.0 and
> 4.0?
So does that mean there's not going to be any 3.x versions between 3.0 and
4.0?
On Tue, 11 Oct 2016 at 23:55 Xiaodi Wu wrote:
> It's described in the swift-evolution GitHub repository readme:
>
> https://github.com/apple/swift-evolution
>
>
>
> On Tue, Oct 11, 2016 at 17:53 Jay Abbott via swift-
> On Oct 11, 2016, at 5:06 PM, Braeden Profile wrote:
>
> Awesome; +1. Does this address the lack of .init(keys:values:)? Would it
> make that addition easier?
No, I don't think this has any bearing on that question. There's a separate
proposal for that sort of initializer that was deferred
> I think the language devs must have some idea how this will work, but
> don't seem to want to share/discuss it at the moment. I was hoping for
> some feedback about my implementation ideas - whether they are along the
> right lines, or way off, or not necessary (because the implementation
> stra
I agree. I like this proposal.
-- E
> On Oct 11, 2016, at 3:38 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> Very elegant solution. Strong +1; no other feedback comes to mind atm.
>
>
> On Tue, Oct 11, 2016 at 4:28 PM, Nate Cook via swift-evolution
> mailto:swift-evolution@swift.org>> wrot
It's described in the swift-evolution GitHub repository readme:
https://github.com/apple/swift-evolution
On Tue, Oct 11, 2016 at 17:53 Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:
> I keep seeing it mentioned that some ideas are out of scope for Swift 4
> phase 1 - I unde
I keep seeing it mentioned that some ideas are out of scope for Swift 4
phase 1 - I understand from this list that phase 1 is to include any
breaking changes then phase 2 (etc?) will be adding more features. That's
all I know about it.
It would be nice to know what phases are on the table and what
That's exactly what this proposal is about. I would like to
keep all enum properties but add an extra feature, so that enums can
store some extra data.
--
| Mateusz Malczak
+---
| mate...@malczak.info
| http://malczak.info
2016-10-11 23:42 GMT+02:00 Braeden Profile :
>
Awesome; +1. Does this address the lack of .init(keys:values:)? Would it make
that addition easier?
> On Oct 11, 2016, at 3:38 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> Very elegant solution. Strong +1; no other feedback comes to mind atm.
>
>
> On Tue, Oct 11, 2016 at 4:28 PM, Nate C
As someone who's hit this performance issue myself, a big +1 from me. The
solution looks like it fits perfectly into Swift.
On Tue, Oct 11, 2016 at 3:01 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
> Looks very nice. +1 here as well.
>
> On Oct 11, 2016, at 4:28 PM
I could if there’s interest. Since we intend on maintaining source
compatibility, it will not result in a simpler implementation, though, since
we’ll need to keep the old code path around for Swift 3 mode. Still worth it?
Slava
> On Oct 11, 2016, at 1:58 PM, Pyry Jahkola wrote:
>
> I was remi
I agree Karl, especially the bit about the difficulty of implementation
being the limiting thing here.
I think the language devs must have some idea how this will work, but don't
seem to want to share/discuss it at the moment. I was hoping for some
feedback about my implementation ideas - whether
Looks very nice. +1 here as well.
> On Oct 11, 2016, at 4:28 PM, Nate Cook via swift-evolution
> wrote:
>
> Introduction
>
> This proposal addresses significant unexpected performance gaps when using
> dictionaries. It introduces type-specific collections for a Dictionary
> instance's keys
Thank you for that clarification. I was confused about where it fitted in.
I discuss it on swift-users.
On Tue, Oct 11, 2016 at 2:51 PM, Chris Lattner wrote:
>
> > On Oct 11, 2016, at 2:34 PM, Tony Constantinides via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Ok,
> > Any o
> On Oct 11, 2016, at 2:34 PM, Tony Constantinides via swift-evolution
> wrote:
>
> Ok,
> Any other feedback from the Swift community other than it does not belong as
> part of Swift? Or get the hell out of here?
> I discussing this issue so people in the Swift community are aware of what I
>
Tony--
First off, welcome to the Swift community! Second, I think you're
misunderstanding the feedback here. The swift-evolution list is not a
mailing list for Swift community discussions in general. It's a mailing
list for proposals to change the core language (how do generics work? how
does cont
So, just to recap, the proposed solution is to help enums expose associated
values via properties, and is not to create enums that are open to extra
unnamed cases (RectSize(width:0,height:10))? What I see is that enums would
still maintain their standing where an instance is just a selection of
Very elegant solution. Strong +1; no other feedback comes to mind atm.
On Tue, Oct 11, 2016 at 4:28 PM, Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:
> Introduction
>
> This proposal addresses significant unexpected performance gaps when using
> dictionaries. It introduces ty
Ok,
Any other feedback from the Swift community other than it does not belong
as part of Swift? Or get the hell out of here?
I discussing this issue so people in the Swift community are aware of what
I am planning to do and have the ability to shape if they they so wish.
Some Technical points
Keep
Introduction
This proposal addresses significant unexpected performance gaps when using
dictionaries. It introduces type-specific collections for a Dictionary
instance's keys and values properties.
New DictionaryKeys and DictionaryValues collections provide efficient key
lookup and mutable acc
+1
ManagedBuffer has been really useful a couple of times, but I never found a use
for ManagedBufferPointer. I can’t even say I’m entirely sure what need it was
originally designed to fulfill.
> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
> wrote:
>
> The purpose of ManagedBuf
Reflection is likely to be tackled in Swift 5, no? So realistically, this
could be on track for Swift 6 or 7. Let's postpone discussion until then.
On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Oct 11, 2016, at 12:40, Anton Zhilin via
> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution
> wrote:
>
> Hello Ted,
> First of all, this topic belongs to reflection, which is specifically stated
> to be out of scope of Swift 4 Phase 1. So all considerations are purely
> theoretical for now.
> That said, I also thought abo
I was reminded of this proposal which seems like an obvious win in clarity.
Still planning to submit it, Slava?
— Pyry
> On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution
> wrote:
>
> on Thu Jun 23 2016, Slava Pestov wrote:
>
>> Simpler interpretation of a reference to a generic t
Fair enough. I defer to both of you.
Thanks, -- E
> On Oct 11, 2016, at 1:41 PM, Robert Widmann wrote:
>
> I agree, though it may seem counterintuitive at first. () is a value of unit
> type that exists here to satisfy the sema’s requirements that all branches
> are destructive, productive o
thank you, Goffredo, Anton, see inline
TedvG
> On 11 Oct 2016, at 21:10, Goffredo Marocchi wrote:
>
> I quite like your builder pattern way of adding properties and methods :).
>
> Sent from my iPhone
>
> On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution
> mailto:swift-evolution@swift
+1. I haven’t found use for it, and I don’t think there is one outside of
stdlib.
~Robert Widmann
> On Oct 10, 2016, at 6:12 PM, Erik Eckstein via swift-evolution
> wrote:
>
> The purpose of ManagedBufferPointer is to create a buffer with a custom
> class-metadata to be able to implement a
I agree, though it may seem counterintuitive at first. () is a value of unit
type that exists here to satisfy the sema’s requirements that all branches are
destructive, productive or defer to another productive branch.
~Robert Widmann
> On Oct 11, 2016, at 2:54 PM, Xiaodi Wu via swift-evolutio
I quite like your builder pattern way of adding properties and methods :).
Sent from my iPhone
> On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution
> wrote:
>
> Hello Ted,
> First of all, this topic belongs to reflection, which is specifically stated
> to be out of scope of Swift 4 Ph
Well, unless I'm mistaken, `()` here is a value. I can replace it with `3`
and the compiler emits a warning about unused results. I'm guessing that
since () is a value of type Void, the warning about unused results isn't
triggered.
While it's true that `Void` causes an error, I can write `Void()` i
I thought this was long gone but today I found out it is still legal:
switch i {
case 4 ... 6: ()
case 3: print("Here")
default: break
}
Is there a motivating factor for keeping this in the language? The compiler
picks up on Void and emits an error. You'd think () would produce the same
results
Hello Ted,
First of all, this topic belongs to reflection, which is specifically
stated to be out of scope of Swift 4 Phase 1. So all considerations are
purely theoretical for now.
That said, I also thought about this problem. The best I could imagine is
something along the following lines:
var bu
> On Oct 11, 2016, at 8:26 AM, Xiaodi Wu via swift-evolution
> wrote:
>
> The following document may inform your discussion here:
> https://github.com/apple/swift/blob/73841a643c087e854a2f62c7e073317bd43af310/docs/proposals/Accessors.rst
Specifically this section, which describes more or less
The following document may inform your discussion here:
https://github.com/apple/swift/blob/73841a643c087e854a2f62c7e073317bd43af310/docs/proposals/Accessors.rst
On Tue, Oct 11, 2016 at 6:42 AM, Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:
> Oh, I see. I’m not sure about
Dynamic Class/Struct Definition At Run Time
At the time of this writing, 11 October 2016, it is not possible to define
arbitrary
classes, structs and maybe other entities dynamically at run time in Swift.
I have some idea about it, expressed in this message.
Creating class and other types dyn
Hi,
I think we are here discussing two different aspects of introducing
this new feature - code syntax and underlying implementation.
In terms of code syntax I would go with first proposal as it seems to
me the simplest approach. When it comes to underlying implementation,
I can imagine that during
Oh, I see. I’m not sure about the dictionary one, that probably depends on
whether the `Dictionary` type could use this addition to make member mutations
O(1). The other example probably wouldn’t benefit from replacing the setter by
a mutator, as there’s nothing to gain here - the implementation
In case c) for example if your set implementation was something like this:
set { _internalDict["propName"] = newValue }
set { if newValue { _int |= SOME_BIT } else { _int &= ~SOME_BIT } }
Could they be implemented as 'mutate'?
On Tue, 11 Oct 2016 at 12:05 Jay Abbott wrote:
> actually scratch po
actually scratch point a) - that's bloody obvious :D
On Tue, 11 Oct 2016 at 11:58 Jay Abbott wrote:
> This is interesting. I'm trying to evaluate your statement that "No setter
> would be needed if a mutation clause is provided" but I can't think exactly
> what the compiler would do in the case
> On 11 Oct 2016, at 12:59, Jay Abbott wrote:
>
> This is interesting. I'm trying to evaluate your statement that "No setter
> would be needed if a mutation clause is provided" but I can't think exactly
> what the compiler would do in the case where there is a 'get' and 'mutate',
> but no 'se
This is interesting. I'm trying to evaluate your statement that "No setter
would be needed if a mutation clause is provided" but I can't think exactly
what the compiler would do in the case where there is a 'get' and 'mutate',
but no 'set'...
a) when you call a non-mutating function;
b) when you as
Just having getters and setters doesn’t allow this (unless the optimiser is
really smart about it). All the current API allows is grabbing whatever the
`get` clause returns, mutating it, and then passing it into the `set` clause,
whatever that does. The `set` clause might not do anything, or wha
This is the latest draft of the proposal:
https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md
Refactor Metatypes
Proposal: SE–0126
Authors: Adrian Zubarev, Anton Zhilin, Brent Royal-Gordon
Status: Revision
Review manager: Chris
> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution
> wrote:
>
> Right. The question is whether we *need* to add stored properties
> out-of-module, and what the use case for that is. To me it seems that adding
> them in-module is by far the more common use case, for the purposes of
> On 11 Oct 2016, at 08:49, Benjamin Spratling wrote:
>
> Howdy,
> The error message is not saying that aFunction throws, it says “??" might
> throw. After all, you supplied a ()rethrows->(Int) to it as its second
> argument, which is wrapping a ()throws->Int, “bFunction()"
> ?? and && and ||
59 matches
Mail list logo