Semi colons;

[Isaac-Leonard]

Three Two One ... Fight? Does BorrowScript use trailing semicolons? I'm in camp yes but don't particularly care either way as long as the weird current edge cases in js are avoided.

[SuperSonicHub1]

In recent versions of ECMAScript, semi-colons are optional in most situations, so I don't see why that still can't be the case.

[mindplay-dk]

To humans, line break is probably the most natural statement separator there is.

Source-code in something like Skew is extremely pleasing to look at - very low noise and low ceremony.

I personally would like to ban semi-colons altogether - and parens in if/while/for-statements for that matter.

[alshdavid]

I feel semicolons should be optional. JS edge cases are weird like

const foo = 'hi'

(function(){
  console.log('this breaks')
})()

But that's okay in my opinion

[WebReflection]

not so weird ... class fields require mandatory semicolons, by standard ...

semicolons are inevitable in JS in some case, so always semicolons is better than sometimes semicolons, hence these should at least be optional, like it is for JS, and TS, as there are already known cases that can't work without semicolons.

Decorators themselves are exploiting absence of semicolons, so chose wisely if you really want to limit the future of this new proposal already to "no semicolon only" syntax.

[SheepTester]

not so weird ... class fields require mandatory semicolons, by standard ...

Class bodies have ASI according to the proposal (note 2). AFAIK the only time class fields need a semicolon is when it's before a generator method, instanceof, or in, or if it's after an uninitialized field named get or set, in addition to before [ (which is already relatively common knowledge). In other words, in almost all cases, semicolons are optional for class fields

[WebReflection]

almost means that semicolons must be allowed, otherwise the project will branch syntax and features from JS without any valid reason. Crockford once said: "if there is one case where a pattern is worse than another, always use the safe/correct pattern" ... never really understood why so many no-semi developers think differently.

[SheepTester]

Semicolons are indeed required to be allowed by any implementation of ECMAScript (and so is ASI). ASI quirks may be reason to always use semicolons, but that's a choice for a JavaScript project/programmer, not an implementation of ECMAScript, to make.

It's undeniable that JavaScript and TypeScript both have ASI, so in the context of BorrowScript, it's whether or not BorrowScript should inherit ECMAScript's ASI rules or deviate from them. If BorrowScript chooses to deviate from ECMAScript, then it'll have to decide how to allow expressions to be continued on multiple lines if it wants to continue having semicolon-optional code

[WebReflection]

yeah ... you know, start with what's there, a whole ASI specification to play with , if you really like ASI (I don't), but starting a new project like this wasting time around the most silly debate after tabs VS spaces for a programming language that work with both ... if you were the author, would you really care, out of everything else really more important to do than ASI?

[mindplay-dk]

Well, no one said this was going to be an ECMAScript implementation?

It says "TypeScript inspired syntax", which doesn't need to imply semicolons.

If the syntax was designed to use line breaks as statement separators, I'm sure it's possible to design the syntax so that visible statement separators aren't necessary?

Semicolon languages are starting to look a bit dated, and I think the semicolons were there more for the sake of the parser than for the human reader - line breaks are much more natural and unambiguous statement separator for the human eye.

[WebReflection]

line breaks are much more natural and unambiguous statement separator

we still need to send \r\n as new lines for headers/cookies on the Web because new lines are easy on the eyes but not unambiguous at all for machines, but fair enough, all I wanted to say is that there is a committee of professionals at TC39 that discussed this plenty and the decision is that there are situations where semicolons are necessary.

Diverging from that for the sake of it will simply branch out a syntax that's been discussed for 20+ years and that worked, despite what developers think, prefer, or actually use (see no-semi movement).

Moving away from the syntax that inspired this project also means being unable to reuse all the tools that just work with such syntax.

Having this debate so early also makes me feel really like we are not contributing at all and we're focusing on the very least important aspect, or already solved problem, this project is bringing in, imho.

I don't have much else to say though, I just wanted to bring in my thoughts around this never-ending, always-useless to date, debate.

[alshdavid]

I just wanted to bring in my thoughts around this never-ending, always-useless to date, debate.

Haha I appreciate you bringing it up, I will close this for now - feel free to reopen the discussion if you feel strongly about semicolons

[mindplay-dk]

all I wanted to say is that there is a committee of professionals at TC39 that discussed this plenty and the decision is that there are situations where semicolons are necessary.

In Javascript they are - no reason a JS-inspired syntax needs to either support or enforce them.

I just wanted to bring in my thoughts around this never-ending, always-useless to date, debate.

It is useless - in the context of Javascript.

That said:

always semicolons is better than sometimes semicolons

This I agree with.

If it has to have semi-colons, don't make them optional - automatic semicolon insertion in JS was the kind of mistake that starts these pointless religious wars.

My only point was, in the context of other syntaxes that were designed without semicolons, this is perfectly feasible - there's no reason a modern parser/syntax should require semicolons. Again, Skew has some of the most beautiful and elegant parser code, and some of the best error messages I've ever seen, in any compiler.

If semicolons are a practical requirement, it's not for any of those reasons - unless there are pressing reason to reference this syntax feature, why even debate the topic? This language won't be source-to-source compatible with either JS or TS - I don't think that's a stated objective? AssemblyScript already covers that.

So, just in general, I hope we don't reference JS closely for all of it's deficiencies.

I don't think any time is too early to debate that. 😅