labath wrote:
> > * The expression `foo["bar"]` tries:
> >
> > * `foo.GetChildWithName("bar")`
> > * `foo.GetChildWithName("[bar]")`
> > * The expression `foo[<expr>]` -- `expr` is evaluated and treated as
> > cases above. If the result of `expr` is not a number or a string -- produce
> > an error
>
>
> I think this is an interesting idea whose usefulness mainly depends on what
> kind of string operations we have in the language. If there's no way to
> construct strings, then I don't think it's very useful. You could write
> things like `some_variable[another_variable]`, but I don't think that's going
> to be useful because for static types (e.g. C structs) you're unlikely to
> have a variable with a value that contains the name of a field, and for types
> with synthetic children the names of the children are not going to have any
> relation to the way it's seen by the code (map<string, string> is still going
> to have a child called `[0]`).
>
> Overall I'd leave this out for the time being because it doesn't impact
> parsing or lexing, just how some (currently invalid) syntax trees can be
> interpreted.
Thinking about this further, I can think of one reason to allow this even
without sophisticated string operations -- because this allows you to access
identifiers with weird child names. This way we could have users write
`obj["a+b"]` for accessing the child `a+b` of object `obj` -- and we wouldn't
"use up" a quote character in the process. This is sort of like how you can
access global variables (even those with weird names) with
`globals()["my_var"]` in python.
I'd still try to avoid things like guessing whether the user forgot to add `[]`
to the name or not..
https://github.com/llvm/llvm-project/pull/123521
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
