Hello everyone,
what if to remove semicolons at the end of each line of code in D like in Python?
Is it worth it?

On Friday, 16 September 2016 at 23:00:08 UTC, eugene wrote:
> Hello everyone,
> what if to remove semicolons at the end of each line of code in D like in Python?
> Is it worth it?

i.e. simply use a newline sign as a line separator

On Friday, 16 September 2016 at 23:01:32 UTC, eugene wrote:
> On Friday, 16 September 2016 at 23:00:08 UTC, eugene wrote:
>> Hello everyone,
>> what if to remove semicolons at the end of each line of code in D like in Python?
>> Is it worth it?
>
> i.e. simply use a newline sign as a line separator

Pointless and not worth breaking everyone's code over

On 17/09/2016 11:00 AM, eugene wrote:
> Hello everyone,
> what if to remove semicolons at the end of each line of code in D like
> in Python?
> Is it worth it?

Also lua would be a better example as it allows for with and without.

On Fri, 16 Sep 2016 23:00:08 +0000, eugene wrote:

> Hello everyone,
> what if to remove semicolons at the end of each line of code in D like
> in Python?
> Is it worth it?

It's more than reinterpreting newline as a semicolon. For instance, we'd probably still want this to work:

someObject.someField.someLongMethodName(
  arg1,
  arg2,
  arg3);

You might look into how javascript does it and what weirdness ensues as a result.

On Saturday, 17 September 2016 at 05:03:17 UTC, Chris Wright wrote:
> On Fri, 16 Sep 2016 23:00:08 +0000, eugene wrote:
>
>> Hello everyone,
>> what if to remove semicolons at the end of each line of code in D like
>> in Python?
>> Is it worth it?
>
> It's more than reinterpreting newline as a semicolon. For instance, we'd probably still want this to work:
>
> someObject.someField.someLongMethodName(
>   arg1,
>   arg2,
>   arg3);
>
> You might look into how javascript does it and what weirdness ensues as a result.

Yup. Every time I write multiline expression in JS, I get uncomfortable thinking whether the browser will interpret as I think or not.

On Saturday, 17 September 2016 at 05:03:17 UTC, Chris Wright wrote:
> someObject.someField.someLongMethodName(
>   arg1,
>   arg2,
>   arg3);
There are no semicolons in an ArgumentList.

> You might look into how javascript does it and what weirdness ensues as a result.
Its weird and uncomfortable at first, but there are only a handful of characters that cause multiple lines to be interpreted as one. Characters like [, (, +, - and ` (es6)

Where it gets a little bit weird is with return statements for instance, since there can be no newline before the expression to be returned. Arrow functions, while statements, etc. have similar constraints. All pretty obvious once you know the rules.

That is pretty much it.

Having said all that, I do think a much better solution to avoid the visual clutter is to make the semicolon transparent in the syntax highlighting.

On Saturday, 17 September 2016 at 02:21:54 UTC, Chris M. wrote:
> Pointless and not worth breaking everyone's code over

why?

On Saturday, September 17, 2016 10:15:57 eugene via Digitalmars-d wrote:
> On Saturday, 17 September 2016 at 02:21:54 UTC, Chris M. wrote:
> > Pointless and not worth breaking everyone's code over
>
> why?

Having semicolons actually serves as a synchronization point for the compiler, which helps it give better error messages. Sure, trying to use newlines that way can work, but it's more problematic - especially when you take stuff like multiline statements into account. D - like C/C++/Java/C# - is not whitespace sensitive, and like those languages, it uses semicolons. There really is no technical reason why getting rid of semicolons improves things, and it does make them at least slightly worse as far as the compiler goes. It's just cleaner to have semicolons, and most D programmers have no problem with that - even prefer it.

In addition, needlessly altering D's syntax like that would make porting C/C++ code to it much harder, which would be a significant problem for a decent chunk of our user base. D's syntax tends to stick with C/C++'s syntax unless it has a compelling reason to do otherwise.

And regardless of whether not having semicolons would be better or not, it would be a huge breaking change to get rid of them, which isn't even vaguely worth it. Sure, D continues to involve, but it's reasonably stable, and we want it to become _more_ stable, not less. It's _way_ past the point that we would consider making a change like this. Doing something like removing semicolons from the language would alienate a huge portion of our user base. Most would consider the change to be objectively worse, and even if they didn't care about whether D had semicolons or not, they would _not_ be pleased to have their code break.

- Jonathan M Davis

On Saturday, 17 September 2016 at 11:03:14 UTC, Jonathan M Davis wrote:
> On Saturday, September 17, 2016 10:15:57 eugene via Digitalmars-d wrote:
>> On Saturday, 17 September 2016 at 02:21:54 UTC, Chris M. wrote:
>> > Pointless and not worth breaking everyone's code over
>>
>> why?
>
> Having semicolons actually serves as a synchronization point for the compiler, which helps it give better error messages. Sure, trying to use newlines that way can work, but it's more problematic - especially when you take stuff like multiline statements into account. D - like C/C++/Java/C# - is not whitespace sensitive, and like those languages, it uses semicolons. There really is no technical reason why getting rid of semicolons improves things, and it does make them at least slightly worse as far as the compiler goes. It's just cleaner to have semicolons, and most D programmers have no problem with that - even prefer it.

There are also language constructs with semicolons inside, I'm not sure it would add that much complexity, but there are some cases that would be ambiguous:

    void filterEven() {
        print("Nothing here")
    }

    auto filterEven(int[] arr) {
        import std.algorithm : filter
        return arr.filter!(x => x%2)
    }

    void main() {
         auto i = [1, 2, 3]
                          .filterEven()
    }

Note how a leading dot means “global scope” but a dot after something means UFCS or method/attribute. What should this program do? If it is akin to “auto i = [1, 2, 3]; .filterEven();” then i is an int[] and the program prints “Nothing here”. But if it is understood as “auto i = [1, 2, 3].filterEven();” then i is whatever type filter returned and nothing is printed.

> In addition, needlessly altering D's syntax like that would make porting C/C++ code to it much harder, which would be a significant problem for a decent chunk of our user base. D's syntax tends to stick with C/C++'s syntax unless it has a compelling reason to do otherwise.

That's the really good reason. Semicolons are a cultural choice more than a technical one but once we've made that choice there's no turning back without loosing nearly all users.

Besides the ability to port code easily from one language to another is important. I have in mind this recent article “Why I'm dropping Rust” (https://hackernoon.com/why-im-dropping-rust-fd1c32986c88). The author tried to port a C++ library but as language constructs are different he wasn't able to do so without having to rethink the architecture from scratch. We want it to be easy to port any project to D.

> And regardless of whether not having semicolons would be better or not, it would be a huge breaking change to get rid of them, which isn't even vaguely worth it. Sure, D continues to involve, but it's reasonably stable, and we want it to become _more_ stable, not less. It's _way_ past the point that we would consider making a change like this. Doing something like removing semicolons from the language would alienate a huge portion of our user base. Most would consider the change to be objectively worse, and even if they didn't care about whether D had semicolons or not, they would _not_ be pleased to have their code break.
>
> - Jonathan M Davis