Re: [swift-evolution] String update

<- buy my book? > * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > <http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf> > * http://agilesolutionspace.blogspot.com/ > <http://agilesolutionspace.blogspot.com/> > > On Jan 11, 2018, at 9:50 AM,

Re: [swift-evolution] [Pitch] Raw mode string literals

I’m beginning to wish I hadn’t tied this proposal so strongly to regular expressions! It is indeed the wrong motivation. Even as a ten year veteran of Perl development I’m not sure we want to bake it into the language quite so tightly (isn’t a part of Foundation?) What would /regex/ represent -

[swift-evolution] [Pitch] Raw mode string literals

Hello S/E, I’d like to put forward a perhaps rather banal change to the Swift lexer primarily intended to make entering regular expression patterns easier. https://github.com/DoubleSpeak/swift-evolution/blob/master/proposals/-raw-string-escaping.md

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

One last try at promoting code generators as an alternative means of importing…. It keeps the complexity out of the compiler and you are able to write the “importer” in the language being imported allowing it to leverage it’s meta data introspection directly. I’ve prepared a playground which

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Integration with Xcode would be straightforward but it’s been Android Studio I’ve most experience with. For that it was just a case of adapting a gradle plugin to add a rebuild phase. If you can’t automate it running a generator when you change the surface of your api is not a big overhead.

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Isn’t there a third way? I wrote a bridge between Swift and Java without having to change the compiler at all by using a code generator to generate bridging Swift rather than having a Java importer. The script introspects the classes/packages you’re interested in using a script and generates code

[swift-evolution] Pitch: [stdlib] Error recovery hook, PR #12025

Hi S/E, I’ve raised a rather speculative PR suggesting a hook be added to stdlib that would allow users to experiment with error recovery in their apps. I’ve been asked to put it forward on Swift Evolution to gather opinions from the wider community about such a design.

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

As this review winds down it seems fair to say the response has been generally favourable with some reservations about whether this should be applied to single line strings as well. I’d include single line strings myself for consistency with multi- line and with other languages myself but that

Re: [swift-evolution] Revisiting SE-0110

Hi Mark, one example of what was possible in Swift 3 but not convenient in Swift4 as it stands is the following: let bookTuples = [(1, "john", "book", "novel", 9.99, []), (2, "john", "book", "novel", 9.99, ["chapt1", "chapt2"])] print("""

Re: [swift-evolution] Revisiting SE-0110

> On 1 Jun 2017, at 17:31, Tommaso Piazza via swift-evolution > wrote: > > >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution > >>> > wrote: > >>> > >>> Yes, I agree. We need to add back

Re: [swift-evolution] [Proposal] Newline escapes in Swift Strings

> On 26 Apr 2017, at 23:40, Xiaodi Wu via swift-evolution > wrote: > > So, independent of whether one thinks this is a good idea or not, the core > team wrote the following: > > > Discussion on the list raised the idea of allowing a line to end with \ to > >

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

Following this thread it reads to me that SE-0168 being accepted without newline escapes was regrettable as it gave us more flexibility in formatting “long strings”. As the core team rejected it on the basis that it was inconsistent with conventional string literals the obvious thing to do is

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On 21 Apr 2017, at 20:27, Ricardo Parada via swift-evolution > wrote: > > From Joe's email: > > "[...] > Discussion on the list raised the idea of allowing a line to end with \ to > "escape" the newline and elide it from the value of the literal; the core > team

[swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

e any chance this is in the pipeline? - John > On 13 Dec 2016, at 02:13, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Mon, Dec 12, 2016 at 6:15 PM, John Holdsworth via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I’m sure it’s been

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

 Thanks again Brent. This version looks great! I think we’re really getting there. > On 13 Apr 2017, at 13:41, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >>

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

be > complete (have line endings unless escaped) by default in a multiline string. > >> On 12 Apr 2017, at 22:31, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> John, why do you think that option 2 is superior to option 3? &

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

endings unless escaped) by default in a multiline string. > On 12 Apr 2017, at 22:31, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > John, why do you think that option 2 is superior to option 3? > > > On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution >

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I think we’re agreeing. Looks like I need to clarify my last post a little. When I included the following strings: let longstring = """\ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \ tempor incididunt ut labore et dolore magna aliqua.

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Finally.. a new Xcode toolchain is available largely in sync with the proposal as is. (You need to restart Xcode after selecting the toolchain to restart SourceKit) I personally am undecided whether to remove the first line if it

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I feel discussion on this proposal is nearing general agreement that while the gist of it it seems reasonable to many there is also not enough detail in it as submitted. Brent has person-fully stepped in and rewritten the draft to translate it into a detailed specification which I’ve updated

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi, John here, the submitter of the proposal. First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake. Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t

[swift-evolution] It's the little things..

As the festive season approaches I thought I’d write a brain dump of a few things I'd hope Santa could bring in his bag for Swift 3.1. No big ideas, just things that bug me day to day and would be backward source compatible. I’m sure it’s been discussed before but I wish static and class vars and

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

> On 25 Sep 2016, at 04:07, Michael Gottesman wrote: > >> init(imageProducer:ImageProducer) { >> withExtendedLifetime(CanvasBase()) { >> super.init(javaObject: $0.javaObject) >> } >> image = createImage(imageProducer) >> } >> >>

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

Sorry, I’m being a little slow on the uptake here. So in future optimised Swift the scope of a variable continuing an object doesn't determine it’s lifetime at all! That seems quite a departure. This means you have to be very careful with contained UnsafePointers indeed. I got as far as needing

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

> On 22 Sep 2016, at 23:57, Michael Gottesman wrote: > >> As a result the following transfer of a Java instance always worked: >> >> init(imageProducer:ImageProducer) { >> let supr = CanvasBase() >> super.init( javaObject: supr.javaObject ) >>

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

f8) { >data.withUnsafeBytes { >_ = to?.write(bytes: $0, count: data.count) >} >} > } > > -Joe > >> On Wed, Sep 21, 2016 at 16:54 John Holdsworth via swift-evolution >> <swift-evolution@swift.org> wrote: >> Hi, >> >> For comp

[swift-evolution] Should Swift apply "statement scope" for ARC

Hi, For complex statements in C++ any temporary instances created in the course of an expression have their lifetime extended to the completion of the current statement after which they are all deallocated en masse. This makes certain types of language usage possible and easier to reason with.

Re: [swift-evolution] [Proposal] Sealed classes by default

Well, I walked into that one :( Sorry to trawl all that up on a Sunday. I get it now. “open” is the new “public”, “public, the new “final” at least as far as classes outside the module are concerned. John > On 15 Aug 2016, at 10:51, Tino Heth <2...@gmx.de> wrote: > > >> Am 14.08.2016 um

[swift-evolution] [Proposal] Sealed classes by default

Hi folks, I see from building the latest Swift-3.0 branch that I’m a little behind the times and this proposal has been accepted :( https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md Is there no way we can revisit this decision? 60 emails

Re: [swift-evolution] multi-line string literals.

I’ve assembled a gist to summarise the main proposals of this thread. https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf At the moment there seem to be four proposals for multi-line strings: 1) Bent’s proposal for continuation quotes where if a conventional string does not

Re: [swift-evolution] multi-line string literals.

> On 5 May 2016, at 14:17, David Hart wrote: > > >> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution >> > wrote: >> >> it's not a secret that I'm not a big fan of the proposal. The third draft >>

Re: [swift-evolution] multi-line string literals.

> On 4 May 2016, at 15:07, L. Mihalkovic wrote: > > Cool job!.. Yup, you proceed by "widening the existing holes" to carry the > missing info (eg Modifiers). Making direct changes to lexCharacter() is a > step I thought might be a bit premature considering

Re: [swift-evolution] multi-line string literals.

… response inline > On May 2, 2016, at 2:23 PM, John Holdsworth > wrote: > >> >>> I'm having trouble getting the `e` modifier to work as advertised, at least >>> for the sequence `\\`. For example, `print(e"")` prints two >>>

Re: [swift-evolution] multi-line string literals.

> I'm having trouble getting the `e` modifier to work as advertised, at least > for the sequence `\\`. For example, `print(e"")` prints two backslashes, > and `print(e"\\\")` seems to try to escape the string literal. I'm currently > envisioning `e` as disabling *all* backslash escapes, so

Re: [swift-evolution] multi-line string literals.

Thanks Brent for pulling together the proposal and summarising this thread. I have to say I still feel most drawn to your “continuation quotes” idea and after some thought the “_” modifier for _”strings”with”quotes”_ also seems sensible. Most of all, for me the appeal of these approaches is

Re: [swift-evolution] multi-line string literals.

This isn’t the best argument but they can be very slow to compile :( > On 24 Apr 2016, at 22:52, Ted F.A. van Gaalen wrote: > > let purpleRain =// in remembrance to one of my favorite artists. > “What’s wrong with concatenating string constants with “ + >

Re: [swift-evolution] multi-line string literals.

It’s +1 from me also. Swift’s Lexer is less than 2000 lines in it’s entirety whereas Perl’s tokeniser is more than 11,000 lines so I don’t think this is a direction we want to head in. Besides, I don’t feel there is a need for more than one type of string as Swift's \() interpolation syntax is

Re: [swift-evolution] multi-line string literals.

ily expressed using Python >> style “””? >> >> John >>> On 22 Apr 2016, at 19:12, Patrick Gili <gili.patric...@gili-labs.com> wrote: >>> >>> This doesn't provide very much flexibility. I'd like to see something more >>> like Perl6's quoting

Re: [swift-evolution] multi-line string literals.

gt; wrote: > > This doesn't provide very much flexibility. I'd like to see something more > like Perl6's quoting constructs: https://doc.perl6.org/language/quoting. > > -Patrick > >> On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution >> <swift-evol

[swift-evolution] multi-line string literals.

I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was suggested in the very first week Swift was open sourced and before that in various radars. https://github.com/apple/swift/pull/2275 The approach taken is as simple as possible defining multi-line

[swift-evolution] Optional dictionary subscripts

This isn’t the most compelling of ideas but a couple of times I’ve found myself writing: if let value = key != nil ? dict[key] : nil {… and was wondering if the syntax could be: if let value = dict[key?] {… The key for dictionaries could be made optional in stdlib but this is probably best