D Compiler as a Library

[Roman D. Boiko]

On Thursday, 19 April 2012 at 12:55:50 UTC, Roman D. Boiko wrote:
> On Thursday, 19 April 2012 at 12:31:24 UTC, Tobias Pankrath 
> wrote:
>
>>> T foo(T)(T x) {
>>> return x.something();
>>> }
>>>
>>> int something(int x) {
>>> return 1;
>>> }
>>>
>>> float something(float x) {
>>> return 1.0;
>>> }
>>>
>>> Now... go and rename the first function named "something". 
>>> What do you do with "x.something()" inside the template... 
>>> rename it or not?

> I would go ReSharper way: present user a tree with all 
> occurrences of related symbols and checkboxes to include or 
> exclude each. Or, in this particular case, display a list of 
> affected types and checkboxes for each. This isn't VERY user 
> friendly, though, but very flexible and reasonable. Give 
> warnings if necessary.
>
> Semantic analysis phase would provide information whether 
> symbol is actually related, or only has the same name (but 
> different semantics and scope).

Respective convenience API would simply provide overloads and 
reasonable defaults for similar cases.

My point is that there is nothing in language itself preventing 
such functionality, if we have semantic analysis. The problem is 
related to user intentions, and decision should be made by the 
user (but the tool should provide good defaults and enough 
information).