|
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035965.html
My experience with XCTest and optionals recently was that XCTest runs in a
separate process and reloads the application for subsequent tests. I
auto-converted some Java code and added force-unwrap everywhere as a
On March 26, 2017 at 12:09:55 AM, Brent Royal-Gordon (br...@architechies.com)
wrote:
On Mar 23, 2017, at 9:01 AM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:
setjmp and longjmp do *not* work well with Swift since they need compiler
support to implement their semantics, and s
On March 25, 2017 at 9:56:03 PM, Gwynne Raskind (gwy...@darkrainfall.org)
wrote:
On Mar 25, 2017, at 19:27, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
On March 25, 2017 at 7:15:59 PM, Elijah Johnson (ejrx7...@gmail.com) wrote:
On March 25, 2017 at 10:24
On March 25, 2017 at 7:15:59 PM, Elijah Johnson (ejrx7...@gmail.com) wrote:
On March 25, 2017 at 10:24:23 AM, Elijah Johnson (ejrx7...@gmail.com) wrote:
On March 23, 2017 at 12:01:48 PM, Joe Groff (jgr...@apple.com) wrote:
On Mar 22, 2017, at 7:25 PM, Elijah Johnson wrote:
On March 22,
On March 25, 2017 at 10:24:23 AM, Elijah Johnson (ejrx7...@gmail.com) wrote:
On March 23, 2017 at 12:01:48 PM, Joe Groff (jgr...@apple.com) wrote:
On Mar 22, 2017, at 7:25 PM, Elijah Johnson wrote:
On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com) wrote:
> On Mar 22, 2017, at
On March 23, 2017 at 12:01:48 PM, Joe Groff (jgr...@apple.com) wrote:
On Mar 22, 2017, at 7:25 PM, Elijah Johnson wrote:
On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com) wrote:
> On Mar 22, 2017, at 4:07 PM, Elijah Johnson wrote:
>
> Hi,
>
> Note that this thread has branched of
On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com) wrote:
> On Mar 22, 2017, at 4:07 PM, Elijah Johnson wrote:
>
> Hi,
>
> Note that this thread has branched off a bit, so my latest proposal and
the “head” of this thread can be found at
https://lists.swift.org/pipermail/swift-evolutio
On March 22, 2017 at 8:48:27 PM, Joe Groff (jgr...@apple.com) wrote:
> On Mar 21, 2017, at 6:27 AM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
>
> I still like the idea of shared memory, but since without additional
threading it can’t have write access
ont-end probably runs like a pre-fork server, but Java
is so stable that there is simply no need for that.
On March 22, 2017 at 1:03:42 PM, Joe Groff (jgr...@apple.com) wrote:
On Mar 6, 2017, at 4:20 PM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
Hi,
I’ve been
jgr...@apple.com) wrote:
On Mar 6, 2017, at 4:20 PM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
Hi,
I’ve been recently considering Swift on the server-side, and there came up
the question, “what happens when a null optional is forcibly unwrapped?”
and the answer wa
I still like the idea of shared memory, but since without additional
threading it can’t have write access inside the new process, I don’t think
that it is a solution for a webserver.
The main concern was just with developers using these universal exceptions
deliberately, along with “inconsistent s
But - that would require a dedicated thread or a thread pool to run
function calls on. Definitely it lacks many of the advantages of shared
objects directly in the process. I would definitely prefer a small memory
leak or inconsistent state. The server could handle existing requests and
restart its
Also the proxies would need to implement some protocol so that they can be
de-proxied when sent back to a shared method, and the proxy object exposed
to the user with a new declaration that accepts only proxies. Like using
MyClass -> MyClassSharedProxy for the proxy class and
class MyClass {
Sounds like a good idea. I assume that Swift would need to compile these
proxies in advance to be sub-classes ie. binary compatible objects that
will forward calls and return proxies. “Value” types can be copied as they
normally are, or wrapped by the user (along with “final” objects which
could be
...@mac.com) wrote:
On Mar 12, 2017, at 7:52 PM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
I don’t know if this feature has yet existed in any languague, but its
pretty simple.
Let say you are preparing data for a JSON encoder. Right now, you would add
t to "union types", which are on the
> frequently rejected proposals list:
>
>
> (hit Send too soon)
>
(My e-mail client hates me today; apologies for the spam)
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>
>
>
>
>
>
> On
b.com/apple/swift-evolution/blob/master/commonly_proposed.md
Regards,
Austin
On Mon, Mar 6, 2017 at 6:27 PM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
> Additionally, not discarding previous comments, one way the language could
> be improved is by replacin
only_proposed.md
Regards,
Austin
On Mon, Mar 6, 2017 at 6:27 PM, Elijah Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
> Additionally, not discarding previous comments, one way the language could
> be improved is by replacing (or rather augmenting) optional binding wit
I don’t know if this feature has yet existed in any languague, but its
pretty simple.
Let say you are preparing data for a JSON encoder. Right now, you would add
to an Dictionary or Array like this one:
let data = [String:Any]();
but what one is really saying is that “Any” is from a number of di
language. Just maybe needs
> some clarification of what exactly is a valid use of the force-unwrap.
> Maybe for interop with Obj-C it should be considered "necessary", for
> example.
>
> 2017-03-07 11:54 GMT-05:00 Josh Parmenter :
>
>>
>> On Mar 6, 2017,
11:54 GMT-05:00 Josh Parmenter :
>
> On Mar 6, 2017, at 7:52 PM, Elijah Johnson via swift-evolution <
> swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
>
> Says: Fix it: Insert !
> Should say: Fix it: Use optional binding.
>
> I agree with
Hi,
I’ve been recently considering Swift on the server-side, and there came up
the question, “what happens when a null optional is forcibly unwrapped?”
and the answer was clearly that not only would the request crash, but the
entire server would also crash, since the server itself is/would be also
volution. You should definitely file a
Radar, though.
Best,
Austin
On Mar 6, 2017, at 7:52 PM, Elijah Johnson via swift-evolution
wrote::
Well, I think that it is far more ingrained into the language and its daily use
than you might realize.
At the very least, someone should correct the XCode w
Additionally, not discarding previous comments, one way the language could
be improved is by replacing (or rather augmenting) optional binding with a
faster syntax.
ex.
func test( name : String?, name2 :String? ){
name! , name2! {
// inside this block, “name” and “name2” are non-optional
24 matches
Mail list logo
