Hi,
I just realised, that the problem is slightly worse than I originally
described. I believed that successful calls in between the actual call the
programmer wanted to make and capturing `errno` are not a problem.
But POSIX seems to suggest [4] that "The setting of errno after a successful
c
I hope we get an answer from the core team as it seems something they must have
considered already. Sounds serious.
Sent from my iPhone
> On 4 Nov 2016, at 08:12, Johannes Weiß via swift-evolution
> wrote:
>
> Hi,
>
> I just realised, that the problem is slightly worse than I originally
> d
Am 2016-11-04 06:55, schrieb Thorsten Seitz:
vars cannot be type narrowed as soon as concurrency comes into play.
That's why Ceylon restricts type narrowing to immutables.
Are you afraid that your variable gets changed under your feet and
afterwards does not conform to the narrowed type any mo
Hi all,
> On 31 Oct 2016, at 21:23, Anders Bertelrud via swift-evolution
> wrote:
>
> * What is your evaluation of the proposal?
-1
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes, this is significant problem that basically prevents Swif
> On Nov 4, 2016, at 1:12 AM, Johannes Weiß wrote:
>
> Hi,
>
> I just realised, that the problem is slightly worse than I originally
> described. I believed that successful calls in between the actual call the
> programmer wanted to make and capturing `errno` are not a problem.
>
> But POSIX
What is your evaluation of the proposal?
General +1, with reservations. Novel elements of the proposed behavior will
need careful evaluation and refinement as we see how they plays out in
practice, with open-mindedness from both users and the core team.
Breaking it down:
+1 on having this feat
> On Nov 4, 2016, at 9:12 AM, Johannes Weiß wrote:
>
> Hi Joe,
>
>>> I just realised, that the problem is slightly worse than I originally
>>> described. I believed that successful calls in between the actual call the
>>> programmer wanted to make and capturing `errno` are not a problem.
>>>
> On 4 Nov 2016, at 17:06, Paul Cantrell via swift-evolution
> wrote:
>
>> Overconstraint is much more of a risk in Swift than in other languages using
>> this style of package management.
>
> …is incorrect.
>
> In particular, note that Ruby does not support using multiple versions of a
> l
Hi Joe,
>> I just realised, that the problem is slightly worse than I originally
>> described. I believed that successful calls in between the actual call the
>> programmer wanted to make and capturing `errno` are not a problem.
>>
>> But POSIX seems to suggest [4] that "The setting of errno af
> On Nov 4, 2016, at 11:20 AM, Boris Buegling wrote:
>
>> On 4 Nov 2016, at 17:06, Paul Cantrell via swift-evolution
>> wrote:
>>
>>> Overconstraint is much more of a risk in Swift than in other languages
>>> using this style of package management.
>>
>> …is incorrect.
>>
>> In particular,
-1, though I do strongly think we should have version pinning.
I agree with the others who believe that dependencies should be pinned by
default. This doesn't mean that you have to check the pin/lock file into
source control. I have a good amount of experience developing apps and
libraries with Co
11 matches
Mail list logo
