Try this in a D file:

foo[] foos;

And you get an error like:

Error: undefined identifier foo, did you mean variable foos?

I know why this happens, is there a way to get it not to happen? Some of these can actually be really puzzling. I've seen stuff like "no identifier foo.bar, did you mean foo.bar?"

-Steve

I agree . :)

While we're on it, there was the recent "New to Dlang stream" discussion. The video there revealed the following error message:

import std.typecons;

void main() {
  to!int;
}

Error: template instance `to!int` template `to` is not defined, did you mean No?

I think Levenstein distance is applied there but to suggest that a human mistook 'to' as 'No' is funny. :) Considering keyboard layouts, it can't be a typo either.

Of course, a better thing would be to suggest importing std.conv like some other error messages do.

The unfortunate thing in the video was 'to' is not searchable on the internet and it took them a long time to figure out how to use a to!string expression. :/

Ali

On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
> The unfortunate thing in the video was 'to' is not searchable on the internet

It's not even searchable on the DLang site (e.g. using site:dlang.org on DuckDuckGo); we should avoid these names. Renaming `to` to `convertTo` would solve that using

    import std.conv : to = convertTo;

when using it. It costs a few keystrokes tho.

On Monday, 12 October 2020 at 17:33:04 UTC, Q. Schroll wrote:
> On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>> The unfortunate thing in the video was 'to' is not searchable on the internet
>
> It's not even searchable on the DLang site (e.g. using site:dlang.org on DuckDuckGo); we should avoid these names. Renaming `to` to `convertTo` would solve that using
>
>     import std.conv : to = convertTo;
>
> when using it. It costs a few keystrokes tho.

On the other hand, it is searchable on dpldocs.info:

    http://dpldocs.info/locate?q=to

Though for some reason std.conv.to is the 4th search result, after core.time.to, std.conv.castFrom.to, and (of all things) arsd.email.IncomingMessage.to.

On Monday, 12 October 2020 at 13:24:17 UTC, Steven Schveighoffer wrote:
> Try this in a D file:
>
> foo[] foos;
>
> And you get an error like:
>
> Error: undefined identifier foo, did you mean variable foos?
>
> I know why this happens, is there a way to get it not to happen? Some of these can actually be really puzzling. I've seen stuff like "no identifier foo.bar, did you mean foo.bar?"

I never find the spell check useful anyway, its one of those seems like a good idea but it is useless in practice in my experience. The 'errors' are almost always typos which are obvious once your at the line in question.

Is there a way to turn it off?

On Monday, 12 October 2020 at 18:01:50 UTC, Paul Backus wrote:
> Though for some reason std.conv.to is the 4th search result, after core.time.to, std.conv.castFrom.to, and (of all things) arsd.email.IncomingMessage.to.

It is arbitrary order since all of them get the same score due to all being an exact match of the given name.

I do need to write a new searcher though, it could be a lot better than it is right now.

On 10/12/20 1:33 PM, Q. Schroll wrote:
> On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>> The unfortunate thing in the video was 'to' is not searchable on the internet
> 
> It's not even searchable on the DLang site (e.g. using site:dlang.org on DuckDuckGo); we should avoid these names. Renaming `to` to `convertTo` would solve that using
> 
>      import std.conv : to = convertTo;
> 
> when using it. It costs a few keystrokes tho.

No, I think this isn't what we need.

I'm watching the video and one key problem they are having is they are not putting dlang on all their searches. D is much less represented on the Internet than it should be. If I search for dlang "template instance to!string template to is not defined", the top result's title is "Errors of missing `std.conv` imports"

But what I think we need to do is formalize and make extendable the awesome feature of the compiler to suggest imports.

For example, if you do:

void main()
{
  writeln("hello world!");
}

It will complain:

Error: writeln is not defined, perhaps import std.stdio; is needed?

As I understand it, these functions to import mappings are hard coded in the compiler. Can we make it not hard coded? And then mere mortals (and not compiler developers) can add these to the list as we notice they should be? Perhaps even someone can write an extractor that generates the mappings for a given library.

This would be huge for newcomers, especially with stuff like this all over our tutorial pages.

-Steve

On 10/12/20 2:06 PM, claptrap wrote:
> On Monday, 12 October 2020 at 13:24:17 UTC, Steven Schveighoffer wrote:
>> Try this in a D file:
>>
>> foo[] foos;
>>
>> And you get an error like:
>>
>> Error: undefined identifier foo, did you mean variable foos?
>>
>> I know why this happens, is there a way to get it not to happen? Some of these can actually be really puzzling. I've seen stuff like "no identifier foo.bar, did you mean foo.bar?"
> 
> I never find the spell check useful anyway, its one of those seems like a good idea but it is useless in practice in my experience. The 'errors' are almost always typos which are obvious once your at the line in question.
> 
> Is there a way to turn it off?
> 

I find it useful when I spell something one character off. Having the correct symbol right next to the wrong one allows me to see the difference easier. Besies, you can just ignore it if you want, it doesn't change much to not see the suggestion.

But sometimes the suggestion makes no sense (as in this case).

I'm just wondering if the system can detect (some of) these nonsense cases.

-Steve

On 10/12/2020 10:04 AM, Ali Çehreli wrote:
> Of course, a better thing would be to suggest importing std.conv like some other error messages do.
> 
> The unfortunate thing in the video was 'to' is not searchable on the internet and it took them a long time to figure out how to use a to!string expression. :/

This is more of a naming problem. "to" as a major name in Phobos is always going to be hopelessly ungreppable. Though it could be added to the special list of names importHint().

"Yes" and "No" are also poor names, the latter is hopelessly ungreppable. Furthermore, they are just redundant to "true" and "false". They never should have been put in Phobos.

The general rule is, the more global a name is, the longer it should be. The more local, the shorter.

The reason is exemplified by this thread.