Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Douglas Gregor via swift-evolution
Sent from my iPhone > On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 5 Sep 2016, at 20:01, Douglas Gregor wrote: >> >> >> >> Sent from my iPhone >> >>> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Brent Royal-Gordon via swift-evolution
> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution > wrote: > > I hope you will not find it too impolite, but this feels like a more dogmatic > decision than I would like. I agree that macro's do not feel pure, but they > allow you to adapt to some

Re: [swift-evolution] #pragma

2016-09-05 Thread isidoro carlo ghezzi via swift-evolution
// isghe: ok Sent from my iPhone > On 05 Sep 2016, at 22:31, Xiaodi Wu wrote: > > I agree: "mark" (IMO) is in the same category as "todo" and "fixme", and all > are bona fide comments. If you wish your code to be disabled without becoming > parsed as a comment, use

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

2016-09-05 Thread Xiaodi Wu via swift-evolution
Likely relevant to this discussion, Chris Lattner's comment in the last thread about changing operator precedence (early August): Some 2c to consider: > 1) Swift 4 is being designed with the ability to all us to make “source > changes" that don’t break existing source code. > 2) It is really

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Goffredo Marocchi via swift-evolution
Sent from my iPhone > On 5 Sep 2016, at 20:01, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi wrote: >> >> >> Sent from my iPhone >> >>> On 5 Sep 2016, at 18:59, Douglas Gregor

Re: [swift-evolution] #pragma

2016-09-05 Thread Xiaodi Wu via swift-evolution
I agree: "mark" (IMO) is in the same category as "todo" and "fixme", and all are bona fide comments. If you wish your code to be disabled without becoming parsed as a comment, use instead `#if false`. On Mon, Sep 5, 2016 at 15:27 Jean-Daniel Dupas via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] #pragma

2016-09-05 Thread Jean-Daniel Dupas via swift-evolution
> Le 5 sept. 2016 à 00:53, isidoro carlo ghezzi via swift-evolution > a écrit : > > Hi all, > > I think the "old style" `#pragma` is necessary in Swift. > Exactly in the same way it is available in C/C++ or Objective-C/C++, or in > something else portable way. > >

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

2016-09-05 Thread Xiaodi Wu via swift-evolution
This suggestion has been pitched earlier and I've expressed my opinion in those earlier threads, but I'll repeat myself here: I'm hugely opposed to such changes to the precedence table. Those of us who work with bitwise operators on a regular basis have memorized their precedence in Swift (and

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Douglas Gregor via swift-evolution
Sent from my iPhone > On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 5 Sep 2016, at 18:59, Douglas Gregor wrote: >> >> >> >> Sent from my iPhone >> >>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi

[swift-evolution] NSString.contains(_:) returns false for empty string argument

2016-09-05 Thread Ole Begemann via swift-evolution
Six weeks ago there was a discussion [1] (and a subsequent fix [2]) about the behavior of `String.hasPrefix(_:)` and `String.hasSuffix(_:)` with empty string arguments. After the fix, `str.hasPrefix("")` always returns `true`. This leads to inconsistent behavior with the `NSString.contains(_:)`

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Goffredo Marocchi via swift-evolution
Sent from my iPhone > On 5 Sep 2016, at 18:59, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi wrote: >> >> Hey Doug, >> >> How do I use it in Swift code without a wrapper, which is understandably

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Douglas Gregor via swift-evolution
Sent from my iPhone > On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi wrote: > > Hey Doug, > > How do I use it in Swift code without a wrapper, which is understandably a > bit pointless, if I still support iOS 9? #if or a wrapper are your best options. - Doug > >

Re: [swift-evolution] [Idea]Why not get dynamically named variables?

2016-09-05 Thread David Sweeris via swift-evolution
That's far more interesting than lasagna recipes :-) More abstractly, if I understand correctly, you want to write some code, which in turn will — at runtime — write its own code, *and* said code should have the ability to interact with the already-written code. Does that sound like an

Re: [swift-evolution] [Idea]Why not get dynamically named variables?

2016-09-05 Thread Tino Heth via swift-evolution
> Am 04.09.2016 um 19:28 schrieb Fayez Hellani via swift-evolution > : > > therefore fetched even easier Really? How should the fetch happen? Imho you'll come to Saagars conclusion when you rethink the problem… Tino ___

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Douglas Gregor via swift-evolution
Sent from my iPhone > On Sep 4, 2016, at 9:05 PM, Brandon Knope wrote: > > Where should the lack of {public} be reported then? > > This seems like it falls under jira and not radar because it's in swift open > source but I'm not 100 percent Overlays are a grey area. Please

Re: [swift-evolution] [Meta] Proposal status page

2016-09-05 Thread Ben Rimmington via swift-evolution
> On 14 Jul 2016, at 09:30, Jacob Bandes-Storch wrote: > > I got sidetracked today and mocked up a proposal "status page": > > http://jtbandes.github.io/swift-evolution/ > > This moves the proposal status info (currently in README.md) into a separate > "source of truth": > >

Re: [swift-evolution] #pragma

2016-09-05 Thread Anton Zhilin via swift-evolution
AFAIK, if one would extend Swift beyond its "official" specification, it could be done using #-directives and @-attributes, like Swift playgrounds use #imageLiteral(...) and friends. It's somewhat equivalent to pragmas of C++. On the other hand, things that are not understood by target compiler,

Re: [swift-evolution] #pragma

2016-09-05 Thread Rien via swift-evolution
Ah :-) Yes that could lead to unexpected behaviour of the IDE. However I would not qualify that as dangerous. The code is indeed excluded as was the intention. Re-introducing the #pragma for that purpose seems a bit OTT to me. Rien. > On 05 Sep 2016, at 10:37, isidoro carlo ghezzi

Re: [swift-evolution] #pragma

2016-09-05 Thread isidoro carlo ghezzi via swift-evolution
I have this code: ``` let tuple = ( MARK: 1, EXPLODE: true, DO_SOMETHINGS_UNDEFINED: true ) ``` If I comment it, because I want to exclude that code to be compiled: ``` // let tuple = ( // MARK: 1, // EXPLODE: true, // DO_SOMETHINGS_UNDEFINED: true // ) ``` what will happen to the IDE?

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

2016-09-05 Thread Goffredo Marocchi via swift-evolution
Hey Doug, How do I use it in Swift code without a wrapper, which is understandably a bit pointless, if I still support iOS 9? Sent from my iPhone > On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution > wrote: > > Where should the lack of {public} be