Ask the compiler syntax, e.g. "_"


#1

Imagine if you could use the placeholder “_” in any location to request error messages giving suggestions based on the context, as a workaround for not having a IDE.

The simplest example would be,

foo._ - this would list all the members & methods of ‘foo’ (& tell you its’ type)

but imagine if you could go further …

fn foo<T:_>( a:T) { a.do_something() } // ask what traits have a method ‘do_something()’

fn foo(a:&X)->Y { _(a) } // ask for functions close to fitting the signature ( &X)->Y fn foo(a:&X)->Z { a._()._()} // ask for any functions X->Y , Y->Z and possible ‘Y’

_::bar(x,y,z) // ask for full paths of any functions bar(..)

foo._.bar - … what member has a sub-member .bar (maybe make it also show,

foo._._.bar foo._._._.bar, i.e. search the object graph… this is a big deal with complex data structures. )

fn foo(a,b,c)->_ {... do stuff...} … Do full inference from calls to ‘foo’, and report what signature this function needs to fit it’s uses… the scenario when you factor code out.

{ ... foo(_) ... } report the arguments ‘foo’ should take

An IDE is so useful because it gives a type based search on the fly as you write code, but that only uses forward information; maybe (like the holes technique in haskell, but more intuitive?) this could leverage Rusts’ 2-way inference for something more useful in other ways… a ‘write my code for me’ engine. Also a future graphical IDE could gather suggestions and put them in drop boxes under the “_”'s and you’d have a pretty special environment…

I think most of my reservations about Rust would go away with something like this… its’ really the power of IDE’s rather than the language that keeps me going back to C++ now.

I suppose parts of the feature could be prototyped without changing the parser, by recognising a conspicuous ident…


#2

Better make an IDE.

Fun fact: I couldn’t post just the above because it was one character below the required 20 chars.


#3

yes an IDE would be great but, (i) this might give lower hanging fruit, (ii) this could still do things a traditional IDE can’t, (iii) this might be a step toward an IDE i.e. getting the AST/Parser into a state where it can make sense of partially written code, (iv) this could still complement and extend what an IDE can do - imagine if a graphical IDE collected completions and stuffed them into drop boxes; I think OOP is popular mostly because you can type “something.” and get a dropbox of potential methods - but imagine if that was generalised to functions and any combinations of argument types … “_(something,foo,” … now the IDE gives me a dropbox of functoins that could fill the _ based on the types of ‘something’ and ‘foo’ … and as I type more arguments, the suggestions are refined


#4

Most of your examples are actually use cases of a hypothetical typed doc search I was thinking about a few months ago, would that be useful for you too?


#5

@eddyb - I’m sure that would be useful too, sounds interesting, maybe you’re thinking of something Hoogle inspired?

What I invisage with this is the convenience of it slotting into the established compile-edit cycle … the tool would have the full context of your current source base (all the build options…); and your focus would stay on source & errors . (when you go back from an IDE to a text editor… you definitely miss the live feel source code has…).

Perhaps most of it should be done in a plugin or separate tool using librustc, to avoid bloating the source base too much, but if it had the most basic case it might spur people on to implement the rest