Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error if function parameter is declared without a name #11

Open
SplittyDev opened this issue Oct 29, 2019 · 4 comments
Open

Error if function parameter is declared without a name #11

SplittyDev opened this issue Oct 29, 2019 · 4 comments
Labels
question Further information is requested
Milestone

Comments

@SplittyDev
Copy link
Collaborator

Test case:

fn foo str -> () => { }
@chronium chronium added this to the Alpha v0.1 milestone Oct 29, 2019
@chronium
Copy link
Owner

chronium commented Oct 30, 2019

Would this syntax maybe have a use with anonymous parameter names maybe?

Syntax ideas:

fn foo str -> str = _

// or

fn foo_bar (i32, i32) -> i32 = _.0 * _.1

For the second example, another thought could be something like:

fn foo_bar (i32, i32) -> i32 = .0 * .0

@chronium chronium added the question Further information is requested label Oct 30, 2019
@SplittyDev
Copy link
Collaborator Author

SplittyDev commented Oct 30, 2019

Yeah, that actually sounds pretty neat.

I like the . syntax more than _. though.
Imo, _ should be used for placeholders and unused variables only.

I'm in favor of allowing arbitrary piping (see #13) using a syntax like:

b |> foo (a, _, c) 

In that case, _ is clearly a placeholder and not to be used as a variable.
That is if we even decide to push that proposal further.

Anyway, this would also become possible:

fn foo (a: i32, _: i32, c: i32) -> i32 = a + c

This use of _ could be nice if a specific function prototype is technically required but not actually used, which is likely to happen in situations using FFI, interface patterns, etc.

@chronium
Copy link
Owner

For the last example,

fn foo (a: i32, i32, c: i32) -> i32 = a + c

would be the preferred method.
That does work in this stage. At least for parsing

@SplittyDev
Copy link
Collaborator Author

SplittyDev commented Oct 30, 2019

That would also work of course. Not sure if it's a good idea consistency-wise though. Mixing typed parameters and just types seems like a weird thing to do. Kinda hurts readability imo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants