Suggestion: Add better function/block termination

[Meai1]

Overall goal: More safety and less ambiguous code, faster reading of code, not just faster typing.

Point 1 Remove implicit returns, require writing 'return'

This is the julia syntax that I consider ideal:

function loop_over_global()
    return 1
end

This is Cone's pythony syntax right now (remember, Julia was created primarily to replace Python as a better alternative)

fn loop_over_global() i32
    1

I mean can you honestly say that the second is easier and less ambiguous to read?

Point 2 Require writing 'end' to end blocks like functions or loops

Here is a julia loop:

for i in x::Vector{Float64}
        s += i
end

The problem I have with python like identation: How can I be sure that I copy pasted some piece of code correctly or not? I have to check every single line if it was pasted with the right identation. This could introduce errors of an absolutely nightmare kind where oh oops, one line of 2000 didnt copy paste correctly and the variable at the end of a loop went outside of the loop which now changes the behavior of the loop or the rest of the program in silent ways. I mean this is C undefined behavior kinds of dangerous.

So we can see that even for data scientists who arguably want to write one-off, quick and dirty code.. the julia authors felt like moving away from Python syntax was best and to make these changes.

[scottmcm]

Counterpoint: C#

Historically, that example in C# looked like

int loop_over_global() {
    return 1
}

But later they explicitly added less-noisy syntax, so one can now write

int loop_over_global() => 1;

Boats did a great job of elaborating on different facets of "explicit" in https://boats.gitlab.io/blog/post/2017-12-27-things-explicit-is-not/ -- can you elaborate on which things you're most interested in here?

[Meai1]

@scottmcm I find that c# syntax bad, Dart has introduced the same convenience syntax and it makes it harder to just look at some code and speed read it with a single glance. I have no problem with implicitness as long as it makes reading code more obvious or faster or just as fast. For example I would never complain that on the lefthand side the type is missing in var x = 5;. That's the kind of stuff that is okay by me. Code has to be obvious. Implicit returns just like the ends of blocks are important locations in code. It should be obvious where they are. When all languages constructs start to look the same, people have a harder time reading code quickly. It's like making a GUI flat, or removing all the icons from a gui or painting all the strawberries on a cake the same color as the cake. There are not that many different constructs in a language, they are allowed to look different in fact.. they should.
For the same reason I told the ziglang author: public/private is irrelevant for most code, lets make that implicit. It's okay to be implicit with that, removing those keywords removes so much needless text on the page and makes reading faster. Whether something is public or private is so rarely important while you are reading code, it's like some metadata if you ever decide to use it from some completely different location. It's crazy to include that in the source code in visible form.
So you see hopefully where I'm coming from, I'm not against implicit infered meaning at all. But it needs to help with reading speed and be obvious.
I had this example:

    pub const Id = enum {
        Return,
        Const,
        Ref
    };

Now imagine for a second if it looked like this instead (forget what you would lose in terms of features, just imagine if for some reason this would be just as powerful)

    Id = enum {
        Return,
        Const,
        Ref
    }

It is so painfully obvious, it's almost offensive how simple it looks right? Well that's where the goal should be. Offensively simple code. I look at this and there is absolutely not a single question I have about it.

[jondgoodwin]

Thanks for the feedback. I will keep your concerns in mind. I can assure you that none of my design decisions result from wanting to make Cone more Pythony or to save keystrokes.

The good news for both your suggestions, is that return may always be explicitly specified and one may explicitly specify curly braces, which turns off significant indentation. So your code can definitely follow the conventions you prefer.

[Meai1]

@jondgoodwin it doesnt work for me:

fn sum() i32  {
	mut sum = 0
	each i in 1 <= 5
		sum += i
	sum
}
		
fn main()
  sum()

Error:

 Error 1003: Expected semicolon - skipping forward to find it
 --> 	each i in 1 <= 5
     	^--- work/test.cone:6:2

[jondgoodwin]

Because once you turn it off, implicit white space is turned completely off for everything inside. At that point you must consistently use curly braces inside (e.g., on the each block). You must also terminate all statements with semicolon, as your example is asking for at the end of 'mut sum = 0'.

[PaulBone]

@jondgoodwin I like that rationale, once it's turned off it's completely off, I'd almost go further and do that for the whole file. it'd make it completely unambiguous what's going on and in a way declares that the file is completely copy-paste-able.

[Meai1]

Ok, I've now tried Python for a while and I actually liked it a lot. It's much faster to type and work with when you dont have to write braces all day. Is it more dangerous? Yes, of course. But on the whole I think it's worth it and indentation problems dont appear as often as you'd think.