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

proposal: spec: support ... TODO statement #35386

Closed
bradfitz opened this issue Nov 5, 2019 · 19 comments
Closed

proposal: spec: support ... TODO statement #35386

bradfitz opened this issue Nov 5, 2019 · 19 comments

Comments

@bradfitz
Copy link
Member

@bradfitz bradfitz commented Nov 5, 2019

From a discussion with @griesemer and @ianlancetaylor, who have different opinions on this:

We could make Go support a ... statement that compiles but fails at runtime, as if you wrote, say, panic("TODO").

Like https://docs.perl6.org/routine/....html

So sample code in space-constrained slides can say func (m *Method) Foo() { ... } and be valid, but mostly so work-in-progress code during development compiles with ..., instead of having to write panic("TODO").

cmd/vet could perhaps fail if any exist in your program, to limit its spread (and prevent it from getting checked in).

It'd be a terminating statement.

In Perl6/Raku, it has to be the only statement in a block it seems.

@gopherbot gopherbot added this to the Proposal milestone Nov 5, 2019
@gopherbot gopherbot added the Proposal label Nov 5, 2019
@tandr

This comment has been minimized.

Copy link

@tandr tandr commented Nov 5, 2019

Would it be possible to provide an example, sorry?

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Nov 5, 2019

Would it be possible to provide an example, sorry?

type R struct {}

func (r *R) Read(p []byte) (n int, err error) { ... }
@robpike

This comment has been minimized.

Copy link
Contributor

@robpike robpike commented Nov 5, 2019

You'd have to make sure 'go vet' allowed it and 'cmd/vet' didn't, which is weird.

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Nov 5, 2019

You'd have to make sure 'go vet' allowed it and 'cmd/vet' didn't, which is weird.

Not sure I follow.

The point is to make go test fail if you have a ... statement anywhere in your package. I just assumed vet would be a means to do that. IIRC, the vet checks done by go test already did/do differ from running vet manually.

@robpike

This comment has been minimized.

Copy link
Contributor

@robpike robpike commented Nov 6, 2019

If go test fails with a ... anywhere, I could never use this feature, as I develop by running go test. I suspect many others are in this situation.

I admire the desire for a way to block out stuff for now, but I don't want that to preclude me testing other parts of the code.

@griesemer

This comment has been minimized.

Copy link
Contributor

@griesemer griesemer commented Nov 6, 2019

One way to look at ... is for it to mean "(compiler, please) fill in the blanks".

We already do this in array literals; e.g., in [...]int{1, 2, 3} the ... means "fill in the obvious array length" (which would be 3 in this case).

Generalizing this idea, len(...) in a[len(...) - 1] could mean "fill in the expression denoting the indexed array" (in this case of course a would be shorter than ... but in general that may not be the case). This has been mentioned in #33359 .

Furthermore, ... in make(...) and new(...) could mean "fill in the type per context". For instance, one might be able to write:

var m map[string]float64
m = make(...) // make a map of m's type

See also #34515.

... is also discussed in conjunction with return statements where a return of the form return ..., err would also mean, "fill in the leading result expressions with the appropriate zero values".
See #21182.

With this general interpretation, ... as a statement would mean "fill in the (obvious) statement" - which there isn't one, so at runtime we get a panic.

It could allow us to compile/type-check incomplete pseudo code as it might be used in a presentation. It would also be quite useful when rapidly developing a new piece of code (where I currently stub out missing pieces with panic(0)).

I'm not convinced this is a good idea yet, but it seems as if it could be reasonably generalized, it's relatively simple, and has interesting use cases. It seems intriguing, especially if the use cases read naturally and almost explain themselves.

Q: Would ...{} mean, use the context-correct type for the composite literal? Not sure.

@ianlancetaylor ianlancetaylor added the Go2 label Nov 6, 2019
@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Nov 6, 2019

@griesemer yesterday I started a blog post about the meaning of _ and ... in Go, and how we should think about them in proposed language changes. You have just scooped most of the post, and better than me. :) Want to do _ next?

One additional piece is an observation from Rog that _ is an identifier and ... isn’t, which has implications for what proposals involve syntax changes. Another observation is that ... clearly means “do what I mean”/“fill this in for me” for array lengths, but less obviously so for variadic function signatures or call sites.

@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Nov 6, 2019

With this general interpretation, ... as a statement would mean "fill in the (obvious) statement" - which there isn't one, so at runtime we get a panic.

If the compiler could not fill in an obvious statement, I’d expect compilation to fail, not a runtime panic.

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Nov 6, 2019

@robpike,

If go test fails with a ... anywhere, I could never use this feature, as I develop by running go test. I suspect many others are in this situation.

I also develop by running go test as I wrote. But go test can return multiple failures at once: I can watch my tests start to pass, while also getting a vet failure.

@robpike

This comment has been minimized.

Copy link
Contributor

@robpike robpike commented Nov 6, 2019

If go vet fails, tests don't run.

@magical

This comment has been minimized.

Copy link
Contributor

@magical magical commented Nov 6, 2019

@bradfitz What's the advantage of using ... for this purpose, rather than panic("TODO") which works today and is more explicit? Just saving a few characters?

You propose that go vet could treat it specially, but presumably go vet could just as easily be made to recognize panic ("TODO").

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Nov 6, 2019

What's the advantage of using ... for this purpose, rather than panic("TODO") which works today and is more explicit? Just saving a few characters?

That's basically it. This came out of a conversation about how Go uses ... today and where we might use it more in the future. (@griesemer explained above)

@deanveloper

This comment has been minimized.

Copy link

@deanveloper deanveloper commented Nov 6, 2019

While the idea is intriguing, I think that panic("TODO") is much more clear, especially to a beginner, as to what happens if you were to call the function

@jimmyfrasche

This comment has been minimized.

Copy link
Member

@jimmyfrasche jimmyfrasche commented Nov 6, 2019

This use of ... feels different than the others proposed. All of the others mean "fill in the logical thing here", but it's not clear to me that this is the logical thing.

It also doesn't feel especially in tune with a language that doesn't allow you to have an unused variable.

If it is a good idea to have something like this, I'd prefer a builtin like todo() which isn't much more to write but is much clearer to read (and easier to grep for allowing a hook to prevent such code from being committed). You could also fake it in earlier versions of Go with func todo() { panic("TODO") }.

@griesemer as far as ...{}, I don't see why that's any clearer than just having {} especially when there are cases when the latter is allowed already.

@alanfo

This comment has been minimized.

Copy link

@alanfo alanfo commented Nov 6, 2019

Kotlin has a TODO() function in its standard library so that would be another option, though I'm not sure what package to put it in.

To be honest though I can't see what's wrong with panic("TODO"). I certainly prefer it to ...

@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Nov 6, 2019

All of the others mean "fill in the logical thing here", but it's not clear to me that this is the logical thing.

Wandering off into semantics, I don't think it's exactly "fill in the logical thing". It's more like just "fill it in". If there's no logical thing to fill in, a Schelling point also works. That said, I'm also in the "just use panic("TODO")" camp. (Although past me apparently decided to spell it panic("not implemented").)

@tandr

This comment has been minimized.

Copy link

@tandr tandr commented Nov 6, 2019

Kotlin has a TODO() function in its standard library

Well, the same way Kotlin has it, we can probably just add a library function todo() (akin to panic()) and not mangle "..." use for this particular case? (The signature would probably be something like panic's one too.)

That said, I do like the @griesemer proposal though about "..." being equivalent to "fill the dots" for the compiler

var m [] map[string]float64
m = make(..., 10) // make a slice of maps, preallocate 10 elements

because typing that stuff in obvious places is not fun. (sorry, my 2¢ to repaint the bike shed)

@awh6al

This comment has been minimized.

Copy link

@awh6al awh6al commented Nov 11, 2019

This is interesting thing, todo() looks great.

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Nov 26, 2019

I'll retract this proposal. It was mostly there for completeness.

I've labeled all these issues with the dotdotdot label for easier searching in the future.

@bradfitz bradfitz closed this Nov 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.