Hello, I posted earlier about the confusion between enum discriminators and new bindings. James Boyden described the desire for consistency, which is a more general version of my concern.
Here's another perspective: IDE support. I propose that the target IDE for a language should be find and grep. ;-) In python, if I want to find every definition of a function, I can grep for "def " (or "def |lambda " perhaps). What if I want to find every reference introduction? No such luck. Have you ever tried to write a grep that finds function prototypes in C? Kind of impossible but kind of doable with hacky approaches that have false positives/negatives. How about C++ with templates? Wouldn't it be nice if one could answer all of these questions with find and grep? 1. What are all of the named function definitions inside this source tree? 2. Where is function foo defined? (Notice, this could be a named function definition or a reference to a function.) 3. Is "bar" ever shadowed in this .rs file? ... etc... Rich IDEs or source analysis tools like ctags are incredibly useful for the language they target, but that's one more language-specific tool that I have to learn, whereas I already know grep. I don't want to propose any specific syntax changes here, I just want to suggest this perspective in syntax design. If rust adopted James's suggestion, we could find|grep for "let" to see where all bindings are declared. That'd be quite useful in some circumstances. As a slight tangent: I'd like to see all of the rust compiler packaged into a clean modular interface which is highly available (perhaps even in std::rust for example), so that IDE / analysis tool authors have a leg up on writing parsers, code prettifiers, etc... Regards, Nathan On Tue, Sep 11, 2012 at 8:36 AM, James Boyden <[email protected]> wrote: > On Wed, Sep 12, 2012 at 1:10 AM, Marijn Haverbeke <[email protected]> wrote: >>> Are you saying that struct destructuring also occurs outside of >>> match constructs, as a stand-alone assignment statement? >> >> Yes, he is, and that fact is one of the major constraints on what >> patterns may look like. The same pattern syntax is used in regular >> assignment and alt matching. > > Ah, thank you for the clarification. I was not aware that such an > operation could occur. (There are no examples of anything like it > in the Tutorial or Reference Manual.) > > I wouldn't be particularly keen on a 'let'-laden syntax like: > let Foo { x: let x, y: let y } = ...; > > The obvious alternative is a version without an initial 'let': > Foo { x: let x, y: let y } = ...; > > But would this be parseable? > > And even if it _were_ parseable, it's still closer to the "subtle" end > of the statement spectrum than I'd like -- you don't really know what > you're looking at until you reach the 4th whitespace-delimited token. > > I'll have to think about this further. > > Thanks, > jb > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
