Hi Chris,
Yes, I did read it again, subscribe to that strategy.
I’ve perhaps over-emphasized the importance of the impact back-breaking changes
.. Still..
The subject title was a bit overloaded too.
I guess it’s between two extremes: that is, between (1) really freezing it and
(2) using Swif
> On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen
> wrote:
>
> imho and after releasing Swift 3.0:
> ===
>
> Existing language elements should never be removed,
>(even if they are frowned upon, which occasionally is caused
> by aspects of subjective opin
> On 08.07.2016, at 00:33, Chris Lattner wrote:
>
> On Jul 7, 2016, at 7:46 AM, Karl wrote:
>> Not only that, but we have compiler fix-its. When there are renaming changes
>> or argument-label changes, I just filter down my Xcode error list, click
>> each one, give it a quick eyeball and hit
For JSONFusion this won't work at all, as the code base is largely Objective-C
with lots of Swift-related annotations and depend on Objective-C and Swift ABI
details to work. The main trick in JSONFusion is property introspection which
don't play nice with Swift yet, and for JSFRemote the main t
On Jul 7, 2016, at 7:46 AM, Karl wrote:
> Not only that, but we have compiler fix-its. When there are renaming changes
> or argument-label changes, I just filter down my Xcode error list, click each
> one, give it a quick eyeball and hit “enter”. I don’t know of other languages
> that have had
> On Jul 7, 2016, at 8:46 AM, Karl via swift-evolution
> wrote:
> It’s nice that you like Swift 3.0 so much, but it still has holes - there are
> plans in the generics manifesto for instance which are basically just limited
> by implementation. We don’t have a stable ABI. Reflection is still f
> On 6 Jul 2016, at 20:28, Ted F.A. van Gaalen via swift-evolution
> wrote:
>
> Hi there
>
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am not
> very happy by having to change
> program source all the time:
>
> Therefore after Swift 3.0
I would disagree to freeze API for 2 years when a large parts of proposal
by brilliants programmers and scientists (that where performance is) have
yet to implement features in 3.1, 3.5 to 4.0 would be ideally to move
fast, break fast before it reach mature stage.
_
I'm very much in the camp that doesn't mind breaking changes; of course we
shouldn't be too cavalier about them either, but if a sound case can be made
for why a breaking change is required, then we shouldn't be afraid to make the
change either.
The biggest example that's impacted me in Swift 3
The designers of Swift have adopted a pragmatic approach to things: get a
language that can be useful practically quickly, then improve it as things go.
Its very Apple-like and I think it makes a lot of sense. We have a lot of
useful changes in Swift 3.0, but the language is still far from compl
Ted,
I basically disagree 100% with everything you wrote. I will not got into much
details, but for me, technology that doesn’t evolve is dead technology.
Moreover, your main argument about large code bases, is not a good one: we now
have migration tools that work quite well. They could be made
Both are examples of languages that do not have a lot of
sytax/features/complexity. Such languages are more easily production-ready from
day 1.
The major issue with Swift and its evolution is how to interact with existing
APIs that are written in another language (ObjC), which is vastly differe
Code compiled well with the original ISO C compiler still compiles well with
the latest C standards.
I just found some of my original Visual Basic .net 2002 code written just after
it was released, and it builds and works beautifully in Visual Basic .net 2015.
(I did not join the Apple Develope
Comments inline (resent to swift evolution)
> On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution
> wrote:
>
> Hi there
>
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am not
> very happy by having to change
> program source a
Regards
LM
(From mobile)
> On Jul 6, 2016, at 8:28 PM, Ted F.A. van Gaalen via swift-evolution
> wrote:
>
> Hi there
>
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am not
> very happy by having to change
> program source all the time:
>
Most source breaking changes will be made in Swift 3. From now on code
should be mostly backwards compatible.
On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:
> Hi there
>
> From the perspective from many active programmers
> that use Swi
Hi there
From the perspective from many active programmers
that use Swift (not objective C anymore) I am not
very happy by having to change
program source all the time:
Therefore after Swift 3.0 is released I’d recommend kindly:
Freeze Swift For Some Time!
Do Not Change AnyThing For At Le
17 matches
Mail list logo
