Seemingly invalid syntax accepted without errors?

[radeusgd]

The following code

type A
    B c = 42+2

main = A.B 2

yields:

(B 2)

I'm not quite sure this is right - it looks like a mixed constructor and method definition.

I imagine what happens is that the 42+2 expression turns out to be the default value for c argument of the constructor.

Indeed,

type A
    B c = 42+2

main = A.B

yields 44.

But it does not seem right - if it were a method

type A
    b c = 42+2

that 42+2 would be the body of the method, not a default argument.

This seems inconsistent and is confusing. I think we should require parentheses or whitespace here:

type A
    B (c = 42+2)

or

type A
    B c=42+2

[radeusgd]

I'm not 100% sure that the current behaviour is wrong, but it looks wrong to me. @kazcw @JaroslavTulach opinions?

[kazcw]

This seems inconsistent and is confusing. I think we should require parentheses or whitespace here:

That's how I feel about it too. This syntax appears in the draft language spec. If no one is attached to it, treating this case as an error would simplify the language (and the parser).

[JaroslavTulach]

Requiring:

type A
    B (c = 42+2)

type A
    B c=42+2

seems fine to me.

[JaroslavTulach]

@jdunkerley suggests that:

type A B c = 42+2

should define A.B function with body of 42+2, but James is OK with that to be an error.

[radeusgd]

@jdunkerley suggests that:

type A B c = 42+2

should define A.B function with body of 42+2, but James is OK with that to be an error.

Enso syntax was keeping a clear distinction between identifiers starting with lowercase to be local variables and methods, and Uppercase to by types and their constructors. We could change that but it feels like it would be a very significant change to the syntax. For example IIRC pattern matching relies on this distinction and without it, it could not know which is a constructor and which is a free binding.