www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Swift removing minor features to piss me off

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
This is what bouncing the rubble looks like.

1. Swift 3 will no longer allow mutable variables as parameters. 
Instead, your parameters will be immutable, or reference (inout). To fix 
this, you can assign your immutable variable to a mutable one 
(immutability is always head immutability in swift), or put this weird 
statement in your function:

var i = i (which you may think causes i to now be mutable, but in 
actuality declares a NEW variable to shadow the old).

2. Swift 3 will no longer accept ++. You must write += 1.

Please, D, don't ever do this kind of stuff! I just gained about 45 
warnings in my iOS project. Most of the var function parameters were 
suggested by the IDE...

-Steve
Apr 28 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
grrr... and they removed C-style for statements (i.e. for(;;))

-Steve
Apr 28 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 April 2016 at 18:53:21 UTC, Steven Schveighoffer 
wrote:

 grrr... and they removed C-style for statements (i.e. for(;;))

 -Steve


I agree with the other people on this list - cleaning up a 
language is great and should be done.
`++` might be a bad example, but (empty) C-style for loops are!
Apr 28 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/28/16 4:01 PM, Seb wrote:

 On Thursday, 28 April 2016 at 18:53:21 UTC, Steven Schveighoffer wrote:

 grrr... and they removed C-style for statements (i.e. for(;;))

 -Steve


 I agree with the other people on this list - cleaning up a language is
 great and should be done.
 `++` might be a bad example, but (empty) C-style for loops are!


Sorry, I should have been clearer. All C style for loops are losing 
support, not just empty ones.

The expressiveness of a C-style for-loop in terms of end condition and 
increment, combined with the ability to declare the loop variables in a 
new scope (BTW, swift doesn't allow arbitrary new scopes) is very nice 
for succinct expression of flow control.

 From the answers I'm getting on stack overflow, swift doesn't have very 
much in the way of higher-order functions for helping with this. That's 
what I'm looking for:

for x in someGenerator(0, endCondition: ..., increment: ...)

Right now, all they have is stride, which increments by a specific 
amount, with a specific end point defined as the same type as your 
variable. Anything else requires a while loop, which then of course 
loses the ability to declare loop variables.

I'm very much annoyed by the "you're doing it wrong" attitude when it 
comes to justifying the removal of these features. If you are going to 
remove a feature, there should be an equivalent way to do it.

-Steve
Apr 28 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 28.4.2016 v 22:20 Steven Schveighoffer via Digitalmars-d napsal(a):


 (BTW, swift doesn't allow arbitrary new scopes)


And D does?
Apr 28 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/28/16 4:36 PM, Daniel Kozak via Digitalmars-d wrote:

 Dne 28.4.2016 v 22:20 Steven Schveighoffer via Digitalmars-d napsal(a):


 (BTW, swift doesn't allow arbitrary new scopes)


 And D does?


Sure.

{
    int i = 0;
    while(i < 100) {...}
}

// i no longer defined

Won't work in swift.

-Steve
Apr 28 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Wierd, I am almost sure it does not work for me last time when I tried :)


Dne 28.4.2016 v 22:54 Steven Schveighoffer via Digitalmars-d napsal(a):

 {
    int i = 0;
    while(i < 100) {...}
 }
Apr 28 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2016 2:32 PM, Daniel Kozak via Digitalmars-d wrote:

 Wierd, I am almost sure it does not work for me last time when I tried :)


That's because in dmd there's the line:

     if (strcmp(user, "Daniel") == 0)
	setScoping(false);

It's a feature!
Apr 28 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 29 April 2016 at 01:36:26 UTC, Walter Bright wrote:

 That's because in dmd there's the line:

     if (strcmp(user, "Daniel") == 0)
 	setScoping(false);

 It's a feature!


That one was really funny!
... or maybe I am just thinking this because it is 3 am here...
Apr 28 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-04-29 03:38, Stefan Koch wrote:


 That one was really funny!
 ... or maybe I am just thinking this because it is 3 am here...


No, it's funny any time of the day :)

-- 
/Jacob Carlborg
Apr 28 2016
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 29/04/16 04:36, Walter Bright wrote:

 On 4/28/2016 2:32 PM, Daniel Kozak via Digitalmars-d wrote:

 Wierd, I am almost sure it does not work for me last time when I tried :)


 That's because in dmd there's the line:

      if (strcmp(user, "Daniel") == 0)
      setScoping(false);

 It's a feature!


Microsoft Windows have APIs that have code substantially like the above.

i.e.:

stdcall SomeWindowsAPI(parameters) {
   if( getProcessName()=="Norton Antivirus" ) {
     // Do something differently
   }
}

If a program is deemed important enough to their echosystem, and that 
program uses an API in a broken (or otherwise non-forward compatible 
way), then they will add exceptions to their API to keep that program 
working.

Shachar
May 02 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 28, 2016 at 08:01:02PM +0000, Seb via Digitalmars-d wrote:

 On Thursday, 28 April 2016 at 18:53:21 UTC, Steven Schveighoffer wrote:

grrr... and they removed C-style for statements (i.e. for(;;))

-Steve


 
 I agree with the other people on this list - cleaning up a language is
 great and should be done.
 `++` might be a bad example, but (empty) C-style for loops are!


I find for(;;) far more logical than other vacuous workarounds like
while(1) or while(true). All you have to do is to blur your eyes and
pretend the (;;) looks like an infinity symbol, and you can read it as
"for-ever", a perfectly fitting name for the infinite loop.

Of course, in an ideal world you'd have a "forever" keyword instead, but
using up an entire keyword just for this one specific kind of loop seems
a little excessive. So for(;;) seems like the perfect balance between
idealism and practicality to me.

Just my $0.02.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured
megaliths that address all questions by piling on ridiculous internal links in
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
Apr 28 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:

 Of course, in an ideal world you'd have a "forever" keyword 
 instead, but using up an entire keyword just for this one 
 specific kind of loop seems a little excessive.


forever: {
   // stuff
   goto hell; // who needs break?????
   // more stuff
} goto forever;
hell:
  {}
Apr 28 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 28, 2016 at 10:49:19PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:

Of course, in an ideal world you'd have a "forever" keyword instead,
but using up an entire keyword just for this one specific kind of
loop seems a little excessive.


 
 forever: {
   // stuff
   goto hell; // who needs break?????
   // more stuff
 } goto forever;
 hell:
  {}


Armed with goto, we can completely dispense with complicated,
hard-to-maintain, and trick-to-use superfluous language constructs like
for, if, while, switch, and so on. Who needs if/else and that convoluted
issue of dangling else's, when you could just write goto and be
absolutely clear what exactly is to happen to control flow? And we can
finally jettison throw, thereby eliminating the need for those
cumbersome nothrow annotations and  nogc issues with creating new
Exception objects.  This will reduce the size of the language, make the
compiler easier to maintain, make external parsers easier to write,
etc.. Sounds like win-win to me.  Who's up for drafting up the DIP? :-P


T

-- 
Only boring people get bored. -- JM
Apr 28 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2016 at 03:11:31 UTC, H. S. Teoh wrote:

 Armed with goto, we can completely dispense with complicated, 
 hard-to-maintain, and trick-to-use superfluous language 
 constructs like for, if


eh `if` is still useful. The others can go though!


But, this might sound nuts, but I still think one of the simplest 
languages I know is assembly language. It just does what you tell 
it, one step at a time, with each line basically looking the 
same, it is light on syntax and language rules (unless you are 
using one of those weird macro assemblers, bleh). Most the 
instructions' behaviors are pretty simple too.

I'm an honest fan and writing it isn't as bad as people say.... 
but indeed, there's a reason we have these other language things; 
simpler language is not necessarily better.

Though I'm on the fence of ++. Sure, I like it, but when I have 
to use a language that doesn't have it, +=1 works just as well (I 
just waste a little time on the edit cycle because I always use 
++ first out of habit.)
Apr 28 2016
next sibling parent reply default0 <Kevin.Labschek gmx.de> writes:
On Friday, 29 April 2016 at 04:06:24 UTC, Adam D. Ruppe wrote:

 Though I'm on the fence of ++. Sure, I like it, but when I have 
 to use a language that doesn't have it, +=1 works just as well 
 (I just waste a little time on the edit cycle because I always 
 use ++ first out of habit.)


I find ++ easier to parse than += 1, because my head-parser can 
avoid looking at a number and remembering that number to 
interpret control-flow/intention :o)

I also must admit that I don't see the benefit of removing for 
loops. There are legitimate use-cases where you really want that 
numerical index, be it because you iterate two arrays of the same 
length simultaneously, or be it because you have to enumerate the 
indices anyways so might as well use them for getting an index:

for(int i = 0; i < 5; ++i)
     arr1[i] += arr2[i];

And

for(int i = 0; i < 5; ++i)
     arr[i].SetIndex(i);

My guess, not knowing Swift, is that you will now implement these 
in a more verbose, harder to read way using while or use some 
concept similar to C#s LINQ or Ds ranges to somehow automatically 
apply this type of functionality.
Both seem way more awkward than a normal for-loop.

Whereas I must admit I could not enumerate any benefit outside 
"slightly, very slightly less complex language" and "it *might* 
stop people from doing really complex things with the index 
inside the loop body, causing bugs", which imho do not outweigh 
the breakage + probably lost convenience in certain cases.
Apr 28 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 29.04.2016 06:51, default0 wrote:

 for(int i = 0; i < 5; ++i)
      arr1[i] += arr2[i];

 And

 for(int i = 0; i < 5; ++i)
      arr[i].SetIndex(i);

 My guess, not knowing Swift, is that you will now implement these in a
 more verbose, harder to read way using while or use some concept similar
 to C#s LINQ or Ds ranges to somehow automatically apply this type of
 functionality.
 Both seem way more awkward than a normal for-loop.


I think it's fine with a D range: `foreach (i; iota(0, 5))` is less 
noisy than the `for` variant.
Apr 28 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
On Friday, 29 April 2016 at 05:34:21 UTC, ag0aep6g wrote:

 On 29.04.2016 06:51, default0 wrote:

 for(int i = 0; i < 5; ++i)
      arr1[i] += arr2[i];

 And

 for(int i = 0; i < 5; ++i)
      arr[i].SetIndex(i);

 My guess, not knowing Swift, is that you will now implement 
 these in a
 more verbose, harder to read way using while or use some 
 concept similar
 to C#s LINQ or Ds ranges to somehow automatically apply this 
 type of
 functionality.
 Both seem way more awkward than a normal for-loop.


 I think it's fine with a D range: `foreach (i; iota(0, 5))` is 
 less noisy than the `for` variant.


`foreach (i; 0..5)` seems to cover 95% of my for uses and it 
looks a lot cleaner. I am actually pretty happy that D has this!
Apr 28 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2016 11:22 PM, Seb wrote:

 `foreach (i; 0..5)` seems to cover 95% of my for uses and it looks a lot
 cleaner. I am actually pretty happy that D has this!


foreach neatly eliminates most fencepost bugs.
Apr 29 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-04-29 07:34, ag0aep6g wrote:


 I think it's fine with a D range: `foreach (i; iota(0, 5))` is less
 noisy than the `for` variant.


foreach (i; 0 .. 5)

-- 
/Jacob Carlborg
Apr 28 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 29.04.2016 08:23, Jacob Carlborg wrote:

 foreach (i; 0 .. 5)


Yeah, but that's special syntax, not a range.
Apr 29 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 29/04/16 14:24, ag0aep6g wrote:


 Yeah, but that's special syntax, not a range.


Does it matter? I thought the idea was to get the same behavior not 
explicitly a range.

-- 
/Jacob Carlborg
May 02 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 02.05.2016 09:45, Jacob Carlborg wrote:

 Does it matter? I thought the idea was to get the same behavior not
 explicitly a range.


default0 said that D's ranges would be more awkward than a for loop. I 
think D's iota is fine.

D's special syntax is even nicer, but it's a language thing. And 
apparently Swift is cutting down on syntax, not adding. Something like 
iota is probably doable in a library. I don't know Swift, though.
May 02 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/2/16 6:55 AM, ag0aep6g wrote:

 On 02.05.2016 09:45, Jacob Carlborg wrote:

 Does it matter? I thought the idea was to get the same behavior not
 explicitly a range.


 default0 said that D's ranges would be more awkward than a for loop. I
 think D's iota is fine.

 D's special syntax is even nicer, but it's a language thing. And
 apparently Swift is cutting down on syntax, not adding. Something like
 iota is probably doable in a library. I don't know Swift, though.


Swift has both builtin syntax and library mechanism similar to iota:

for i in 0..<5 // [0 to 5)
for i in 0...5 // [0 to 5]
for i in 0.stride(to: 5, by: 1) // [0 to 5)
for i in 0.stride(through: 5, by: 1) // [0 to 5]

You can also hack with where expressions the builtin range syntax to 
skip values like iota, but I'm almost positive this doesn't perform 
well, or at least won't in complex situations:

for i in 0..<10 where i % 2 == 0 // even numbers less than 10

I think for-in (swift) and foreach (D) are both fantastic for iterating 
a straight range or pre-determined sequence. I would never use for loops 
for a straightforward index progression (and ideally, I would ignore the 
index if at all possible).

However, there are cases where I pull out the for loop because the 
ending condition is complex, or strangely related to the index variable, 
or the increments aren't regular. For loops have so much power in such a 
succinct syntax, I can't understand why anyone would shun them as taboo 
or error prone. Seems like it's more a philosophical decision than 
practical or helpful.

And anyone who says "bleh, you can just use a while loop if you need 
that" I want to beat with a semi-colon over the head.

-Steve
May 02 2016
parent default0 <Kevin.Labschek gmx.de> writes:
On Monday, 2 May 2016 at 14:32:30 UTC, Steven Schveighoffer wrote:

 On 5/2/16 6:55 AM, ag0aep6g wrote:

 And anyone who says "bleh, you can just use a while loop if you 
 need that" I want to beat with a semi-colon over the head.

 -Steve


Apparently, Swift also does not have goto. For all languages that 
do have it, why use while at all if you have goto and if at your 
disposal? It's so much more general and powerful and simpler 
anyways :^)

Though I suppose for Swift just using recursion may do as an 
alternative to while. No need to introduce a new keyword/new 
syntax for something you can already easily do using a simple 
combination of other features, right?
May 02 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2016 9:06 PM, Adam D. Ruppe wrote:

 But, this might sound nuts, but I still think one of the simplest languages I
 know is assembly language. It just does what you tell it, one step at a time,
 with each line basically looking the same, it is light on syntax and language
 rules (unless you are using one of those weird macro assemblers, bleh). Most
the
 instructions' behaviors are pretty simple too.

 I'm an honest fan and writing it isn't as bad as people say.... but indeed,
 there's a reason we have these other language things; simpler language is not
 necessarily better.


You're right. I've written a lot of assembler code for different processors, 
including the entire Empire game (!).

The trouble is, you can't change data structures or algorithms without doing 
complete rewrites, and that is so daunting that nobody ever does it.

Also, assembler code is many, many more lines than a compiled language, meaning 
that the complexity to the programmer is far more, too.
Apr 28 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-04-29 00:37, H. S. Teoh via Digitalmars-d wrote:


 Of course, in an ideal world you'd have a "forever" keyword instead, but
 using up an entire keyword just for this one specific kind of loop seems
 a little excessive. So for(;;) seems like the perfect balance between
 idealism and practicality to me.


In an ideal world the language would support trailing delegate syntax 
allowing this to work without any language support:

forever {
}

Translated to:

forever({

});

I'm pretty sure Swift supports trailing delegate syntax.

-- 
/Jacob Carlborg
Apr 28 2016
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Friday, 29 April 2016 at 06:27:07 UTC, Jacob Carlborg wrote:

 In an ideal world the language would support trailing delegate 
 syntax allowing this to work without any language support:

 forever {
 }

 Translated to:

 forever({

 });


Or maybe with macros supporting a trailing statement as the last 
argument:

macro forever($(Statement st));

$forever {
}

That way it's clearer that magic is happening, but also macros 
are by definition inlined. It also doesn't need braces for a 
single statement.

A complication with the delegate way is break/continue/return in 
the statement block, but I suppose it already works for opApply.
Apr 29 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 29/04/16 14:06, Nick Treleaven wrote:


 Or maybe with macros supporting a trailing statement as the last argument:

 macro forever($(Statement st));

 $forever {
 }


I tried to be a bit conservative, I don't mind macros :)

-- 
/Jacob Carlborg
May 02 2016
prev sibling parent Enamex <enamex+d outlook.com> writes:
On Friday, 29 April 2016 at 12:06:40 UTC, Nick Treleaven wrote:

 A complication with the delegate way is break/continue/return 
 in the statement block, but I suppose it already works for 
 opApply.


I'm curious: what does this actually lower to when compiling?
May 02 2016
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:

 I find for(;;) far more logical than other vacuous workarounds 
 like
 while(1) or while(true).


It's only because of C that all the for arguments can be left 
out, I'd rather have:

while {...}

I.e. it defaults to true. 'A while' is an interval of time, 'for' 
isn't.
Apr 29 2016
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 28.04.2016 22:01, Seb wrote:

 I agree with the other people on this list - cleaning up a language is
 great and should be done.
 `++` might be a bad example, but (empty) C-style for loops are!


Leave those alone.
Apr 28 2016
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 28 April 2016 at 18:53:21 UTC, Steven Schveighoffer 
wrote:

 grrr... and they removed C-style for statements (i.e. for(;;))


I can understand wanting to remove bad ideas, but 1) removing 
something this fundamental to the language and 2) removing 
something that not only doesn't lead to bad code and has 
technical merits makes this completely baffling and unacceptable.

Looking at the proposal to remove it, 
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c
style-for-loops.md, if you read between the lines it seems the main reason they
wanted to remove it was to reduce the need for ++ and --.
Apr 28 2016
prev sibling next sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer 
wrote:

 Please, D, don't ever do this kind of stuff! I just gained 
 about 45 warnings in my iOS project.


… and what? This statement alone is hardly an argument. Both 
those warnings are trivial to fix in an automated fashion; in 
fact, you pointed out the possible rewrites yourself. Fixing the 
warnings and verifying the changes takes way less time than 
tracing down and addressing even a simple application bug, yet 
the language is substantially cleaner as a result. This is 
exactly the sort of changes D needs more of.

  — David
Apr 28 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/28/16 3:21 PM, David Nadlinger wrote:

 On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer wrote:

 Please, D, don't ever do this kind of stuff! I just gained about 45
 warnings in my iOS project.


 … and what? This statement alone is hardly an argument. Both those
 warnings are trivial to fix in an automated fashion; in fact, you
 pointed out the possible rewrites yourself. Fixing the warnings and
 verifying the changes takes way less time than tracing down and
 addressing even a simple application bug, yet the language is
 substantially cleaner as a result. This is exactly the sort of changes D
 needs more of.


And both warnings achieved nothing in terms of preventing bad code. Like 
absolutely nothing.

A function like this (actual function in my code):

func distRange(var segment0: NRMShapeSegment, var segment1: 
NRMShapeSegment, var segment2: NRMShapeSegment, minLength: CGFloat) -> 
(CGFloat, CGFloat)

Now must have 3 var statements at the beginning to identify the 
parameters as var. What exactly does this achieve? BTW, xcode does not 
provide a mechanism to fix this automatically, I'd have to write a 
script to do it.

It's like we're back to non-ANSI C style parameters.

And as far as the ++ to += 1, sure, that is an easy fix. But what is the 
benefit? If ++ was not there originally, then I wouldn't care, but now I 
have to go through and change 15 lines of code for no flipping reason. 
At least xcode suggests the fix and will do it for me.

I also have several for loops that I have no idea how to rewrite. Maybe 
you can help: 
http://stackoverflow.com/questions/36923799/swift-equivalent-for-loop-complex-condition

I hope this doesn't happen to D.

-Steve
Apr 28 2016
prev sibling next sibling parent Thiez <thiezz gmail.com> writes:
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer 
wrote:

 var i = i (which you may think causes i to now be mutable, but 
 in actuality declares a NEW variable to shadow the old).


So how would you tell the difference, and why would you care?

Swift uses LLVM, so everything gets converted to static single 
assignment form during compilation anyway: all assignments 
"actually" declare a new variable to shadow the old.
Apr 28 2016
prev sibling next sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer 
wrote:

 1. Swift 3 will no longer allow mutable variables as 
 parameters. Instead, your parameters will be immutable, or 
 reference (inout). To fix this, you can assign your immutable 
 variable to a mutable one (immutability is always head 
 immutability in swift), or put this weird statement in your 
 function:

 var i = i


Seems reasonable given that code could mutate a variable 
accidentally, e.g. due to a typo.


 2. Swift 3 will no longer accept ++. You must write += 1.


For a new language, fine, but (assuming increment is a statement 
not an expression) removing this and C for probably isn't worth 
the annoyance.
Apr 28 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/28/16 3:39 PM, Nick Treleaven wrote:

 On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer wrote:

 1. Swift 3 will no longer allow mutable variables as parameters.
 Instead, your parameters will be immutable, or reference (inout). To
 fix this, you can assign your immutable variable to a mutable one
 (immutability is always head immutability in swift), or put this weird
 statement in your function:

 var i = i


 Seems reasonable given that code could mutate a variable accidentally,
 e.g. due to a typo.


If you don't want to mutate it, don't put var in the parameter name. I 
put var there because I wanted to mutate it. Swift requires that 
already. It just now won't let you do it in the parameter declaration, 
you have to declare a new variable and use that if you want mutation.

-Steve
Apr 28 2016
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Thursday, 28 April 2016 at 19:45:47 UTC, Steven Schveighoffer 
wrote:

 If you don't want to mutate it, don't put var in the parameter 
 name. I put var there because I wanted to mutate it. Swift 
 requires that already. It just now won't let you do it in the 
 parameter declaration, you have to declare a new variable and 
 use that if you want mutation.


OK, didn't realise var was required for the parameter before. 
Sounds like they are breaking the language just to enforce a 
philosophical point about a function's implementation choices not 
being visible to the caller. Obviously not worth it at this stage.
Apr 28 2016
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 04/28/2016 02:49 PM, Steven Schveighoffer wrote:

 This is what bouncing the rubble looks like.

 1. Swift 3 will no longer allow mutable variables as parameters.
 Instead, your parameters will be immutable, or reference (inout). To fix
 this, you can assign your immutable variable to a mutable one
 (immutability is always head immutability in swift), or put this weird
 statement in your function:

 var i = i (which you may think causes i to now be mutable, but in
 actuality declares a NEW variable to shadow the old).

 2. Swift 3 will no longer accept ++. You must write += 1.

 Please, D, don't ever do this kind of stuff! I just gained about 45
 warnings in my iOS project. Most of the var function parameters were
 suggested by the IDE...

 -Steve


Not surprised. Removing features is all the rage in the software world 
these days. This is one fad I can't wait to see die. Hopefully this one 
won't drag on as ridiculously log as pants-sagging did, but I'm not 
holding my breath.

I say forget playing the "fire and motion" game. Just avoid the big five 
"our way-of-the-week or the highway" trend-factories (Google, Apple, 
Mozilla, Microsoft and Gnome) and everything should be (relatively) fine.
Apr 28 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2016 8:44 PM, Nick Sabalausky wrote:

 Hopefully this one won't drag on
 as ridiculously log as pants-sagging did,


Did? past tense? Dang, I'm out of step again. I better get a belt.
Apr 28 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 29 April 2016 at 03:44:47 UTC, Nick Sabalausky wrote:

 Not surprised. Removing features is all the rage in the 
 software world these days. This is one fad I can't wait to see 
 die. Hopefully this one won't drag on as ridiculously log as 
 pants-sagging did, but I'm not holding my breath.

 I say forget playing the "fire and motion" game. Just avoid the 
 big five "our way-of-the-week or the highway" trend-factories 
 (Google, Apple, Mozilla, Microsoft and Gnome) and everything 
 should be (relatively) fine.


Actually, I did a bit of Java 8 programming recently and although 
I would complain about Java developing ridiculously slowly as a 
language (e.g. lambda support), I found that it is refreshingly 
conservative :-) Yes, there are loops, semicolons and operators, 
just like granny used to make them!

I'm glad Steve posted this here, because whenever a new fancy 
"must have" language is promoted, my attitude is: lay back, relax 
and watch it calmly. First Go and Rust, now Swift. We'll see. So 
far D has served me well.
Apr 29 2016
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
I think Swift is not yet stable. So if you want to use it you 
have to deal with language changes (D2 is stable).

In a modern language ++ and -- are OK only if they return void. 
Otherwise they are bug-prone and allow people to write less 
readable code.

C for() loops are powerful, but a bit too much bug prone and they 
encourage too much compressed code. Better to push reasonable 
coding standards inside the language itself.

Only const function arguments looks a bit excessive in 
defulting-to-const language, but I think it's acceptable if you 
have a way to make them mutable.

It seems Swift is copying several things from Rust. Perhaps Swift 
is going to become more popular than Rust (because Rust is more 
bondage&discipline, less handy because of manual memory 
management, more fussy, and usually fitter for system coding, 
unlike Swift that is more general purpose, on the other hand Rust 
is a bit more free than Swift now).

Bear hugs,
bearophile
Apr 29 2016