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…