[OT] Modules dropped out of C++17

[Steven Schveighoffer via Digitalmars-d]

On 6/10/15 8:52 AM, John Colvin wrote:
> On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote:
>> On 6/9/15 4:06 AM, Brian Schott wrote:
>>> On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote:
>>>> Also, you say 5 seconds as if that's a short amount of time.
>>>> If it takes an automatic scanner 5 seconds, it means the amount
>>>> of coverage it needs to perform is huge.
>>>
>>> If anybody was wondering why DCD doesn't support UFCS, this is the
>>> answer. I can't find a way to make it fast, useful, or compact in terms
>>> of memory use.
>>
>> I can't see how a UFCS lookup is any slower than a normal function
>> lookup. It's just a rewrite.
>>
>> i.e.:
>>
>> a.foo
>>
>> 1. try finding member foo on type a.
>> 2. try finding function foo
>>   a. If found, find overload that will take a.
>>
>> What happens as you type:
>>
>> foo(a
>>
>> ??? how is it any different?
>>
>
> One problem is that any auto-complete list becomes completely unmanageable.

OK, I see the problem. When you type 'a.' then if you put up the list of 
members and UFCS functions available, then that list may be huge (and 
possibly filled with useless calls). That definitely is an issue. 
However, I think DCD should still support that option. A UI for an ide 
could be:

1. Lookup members, add to the list a "UFCS..." button at the bottom.
2. When user clicks on that button, re-query DCD for all functions that 
take the object as the first parameter, then fill in that list.
3. If user continues to type in a UFCS method, and that doesn't match 
any members, the autocomplete should start looking for functions that 
start with that text.

It would be a shame if DCD doesn't show you functions like arr.empty.

However, does DCD support querying a function's parameters when it's a 
UFCS function? That should at least be manageable.

-Steve