Re: [lldb-dev] Making changes to the SB API

Overloading with different numbers of arguments works with no problems, and we use that in a bunch of places in the SB API. I seem to remember that SWIG doesn't always get more subtle overloading (float vrs. double) right, but I can't bring a specific example to mind. Anyway, Greg's solution s

Re: [lldb-dev] Making changes to the SB API

Thanks. I wasn't sure how well C++ overloading works with SWIG, that's definitely a more ergonomic solution. On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton wrote: > > > On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > What is the governing philosop

Re: [lldb-dev] Making changes to the SB API

> On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev > wrote: > > What is the governing philosophy around making changes to the SB API? The "SB > API Coding Rules " > page establishes the practices on how to avoid introducing accidental >

Re: [lldb-dev] Making changes to the SB API

For better or worse you need to make a separate function. An alternative idea that has been floated is to start making a version 2 SB API and then eventually deprecate the current API, but probably due to the amount of work involved and the cost/benefit ratio, nobody's ever really taken point on i

[lldb-dev] Making changes to the SB API

What is the governing philosophy around making changes to the SB API? The "SB API Coding Rules " page establishes the practices on how to avoid introducing accidental incompatibility, but what about the cases where there's a case for intentionally maki