April 28, 2016
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.

April 29, 2016
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.)
April 29, 2016
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.
April 28, 2016
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.

April 28, 2016
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.

April 29, 2016
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.
April 29, 2016
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!
April 29, 2016
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
April 29, 2016
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
April 29, 2016
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