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
> 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
// 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
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
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
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>
> 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.
>
>
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
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
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(_:)`
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
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
>
>
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
> 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
___
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
> 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":
>
>
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,
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
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?
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
20 matches
Mail list logo