www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Spell checking errors can be hilarious

reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 12 2020
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 12 2020
next sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
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.
Oct 12 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
Oct 12 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Oct 12 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2020 11:10 AM, Adam D. Ruppe wrote:

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


There's nothing wrong with the search engine. There's a LOT wrong with global 
symbols named "to".
Oct 12 2020
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/12/20 1:08 PM, Walter Bright wrote:


 There's nothing wrong with the search engine. There's a LOT wrong with 
 global symbols named "to".


Luckily, D does not have a global name space. Half kidding... :)

Ali
Oct 12 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 12 October 2020 at 20:08:38 UTC, Walter Bright wrote:

 There's nothing wrong with the search engine.


oh it needs some work. I wrote a custom one specifically for D 
and while I'm reasonably happy with that it still has some missed 
potential and bugs.

Like http://dpldocs.info/locate/?searchTerm=Socket.select 
shouldn't be empty. And it should do a better job with the 
cross-package results.

Searching for D stuff is legitimately a pain. My search engine is 
better than most but it is still really just mediocre.


 There's a LOT wrong with global symbols named "to".


Gotta disagree with this too. D's module system handles the name 
beautifully and `to` has been a smashing success with few 
problems in use. The response most people have with it is "wow 
that's the easiest thing I've ever seen in any language".

New users just need a quick point in the right direction to 
understand what it is.
Oct 12 2020
next sibling parent Tobias Pankrath <tobias+dlang pankrath.net> writes:
On Tuesday, 13 October 2020 at 03:28:38 UTC, Adam D. Ruppe wrote:

 Gotta disagree with this too. D's module system handles the 
 name beautifully and `to` has been a smashing success with few 
 problems in use. The response most people have with it is "wow 
 that's the easiest thing I've ever seen in any language".


+1
Oct 12 2020
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 11:28 PM, Adam D. Ruppe wrote:

 Gotta disagree with this too. D's module system handles the name 
 beautifully and `to` has been a smashing success with few problems in 
 use. The response most people have with it is "wow that's the easiest 
 thing I've ever seen in any language".


Finally someone said it. You can pry "to" outta my cold dead hands.
Oct 13 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 13, 2020 at 09:15:54AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 10/12/20 11:28 PM, Adam D. Ruppe wrote:

 Gotta disagree with this too. D's module system handles the name
 beautifully and `to` has been a smashing success with few problems
 in use. The response most people have with it is "wow that's the
 easiest thing I've ever seen in any language".


 
 Finally someone said it. You can pry "to" outta my cold dead hands.


Me too!  std.conv.to is one of the coolest things about D. If it's
removed, I will die a little inside.


T

-- 
He who laughs last thinks slowest.
Oct 13 2020
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/13/20 4:11 PM, H. S. Teoh wrote:

 On Tue, Oct 13, 2020 at 09:15:54AM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:



 Finally someone said it. You can pry "to" outta my cold dead hands.


 
 Me too!  std.conv.to is one of the coolest things about D. If it's
 removed, I will die a little inside.


Ok, me four. :)

I've defined 'as' as well but as a member function template. Something like:

   buffer.as!long
   buffer.as!(int[])  // which parses the length first

Ali
Oct 13 2020
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 13 October 2020 at 13:15:54 UTC, Andrei Alexandrescu 
wrote:

 On 10/12/20 11:28 PM, Adam D. Ruppe wrote:

 Gotta disagree with this too. D's module system handles the 
 name beautifully and `to` has been a smashing success with few 
 problems in use. The response most people have with it is "wow 
 that's the easiest thing I've ever seen in any language".


 Finally someone said it. You can pry "to" outta my cold dead 
 hands.


+1
Oct 14 2020
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 4:08 PM, Walter Bright wrote:

 On 10/12/2020 11:10 AM, Adam D. Ruppe wrote:

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


 
 There's nothing wrong with the search engine. There's a LOT wrong with 
 global symbols named "to".


This is one of those cases I'm happy we can't change names.
Oct 13 2020
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 2:10 PM, Adam D. Ruppe wrote:

 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.


Sort exact matches by "least nested" maybe?
Oct 13 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2020 11:01 AM, 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.


Just shoot me now!
https://www.youtube.com/watch?v=LyPFQKpRnd0
Oct 12 2020
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 12 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2020 11:17 AM, Steven Schveighoffer wrote:

 As I understand it, these functions to import mappings are hard coded in the 
 compiler.


https://github.com/dlang/dmd/blob/master/src/dmd/imphint.d

Of course, this won't work for "to" since there are multiple declarations of 
"to" in Phobos (shoot me now).
Oct 12 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/20 4:11 PM, Walter Bright wrote:

 On 10/12/2020 11:17 AM, Steven Schveighoffer wrote:

 As I understand it, these functions to import mappings are hard coded 
 in the compiler.


 https://github.com/dlang/dmd/blob/master/src/dmd/imphint.d
 
 Of course, this won't work for "to" since there are multiple 
 declarations of "to" in Phobos (shoot me now).


What do you mean? Just add "to" : "std.conv". Is there a problem with it?

But better would be a customizable list for the compiler to read (only 
in the case of an unresolved symbol), then you aren't limited to a 
hard-coded list.

-Steve
Oct 12 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2020 1:46 PM, Steven Schveighoffer wrote:

 What do you mean? Just add "to" : "std.conv". Is there a problem with it?


"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."

   -- Paul Backus
Oct 12 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/20 5:37 PM, Walter Bright wrote:

 On 10/12/2020 1:46 PM, Steven Schveighoffer wrote:

 What do you mean? Just add "to" : "std.conv". Is there a problem with it?


 
 "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."
 


All of those are type members, one is not even in Phobos.

A member function or field has nothing to do with suggesting an import 
-- if it was part of the type, it would be there to use, and would be a 
different kind of error if you used it wrongly.

A much more useful search would be a different issue than suggesting an 
import when *no* symbol is found.

-Steve
Oct 12 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/20 7:44 PM, Steven Schveighoffer wrote:

 On 10/12/20 5:37 PM, Walter Bright wrote:

 On 10/12/2020 1:46 PM, Steven Schveighoffer wrote:

 What do you mean? Just add "to" : "std.conv". Is there a problem with 
 it?


 "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."


 
 All of those are type members, one is not even in Phobos.


Actually, core.time.to is not a member function, and I've run into 
problems with it in the past (in terms of error messages).

It can't be a member function, because then it disables uses like to!string.

I think we should change the name of that particular function, but I've 
never used it, so I don't know how disruptive that would be.

-Steve
Oct 12 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2020 4:52 PM, Steven Schveighoffer wrote:

 I think we should change the name of that particular function, but I've never 
 used it, so I don't know how disruptive that would be.


For std2021, there should be no 2 letter names.
Oct 12 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 8:36 PM, Walter Bright wrote:

 On 10/12/2020 4:52 PM, Steven Schveighoffer wrote:

 I think we should change the name of that particular function, but 
 I've never used it, so I don't know how disruptive that would be.


 
 For std2021, there should be no 2 letter names.


"No".
Oct 13 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2020 6:15 AM, Andrei Alexandrescu wrote:

 On 10/12/20 8:36 PM, Walter Bright wrote:

 For std2021, there should be no 2 letter names.


 "No".


That leaves me unsympathetic to claims that the spellchecker/importhinter is 
"broken" and the examples are "to" and "No". A disproportionately large number 
of typos will be matched to them.
Oct 13 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/13/20 9:59 PM, Walter Bright wrote:

 On 10/13/2020 6:15 AM, Andrei Alexandrescu wrote:

 On 10/12/20 8:36 PM, Walter Bright wrote:

 For std2021, there should be no 2 letter names.


 "No".


 
 That leaves me unsympathetic to claims that the 
 spellchecker/importhinter is "broken" and the examples are "to" and 
 "No". A disproportionately large number of typos will be matched to them.


void main()
{
     auto x = to!string(1);
}

Error: template instance to!string template to is not defined

BUT you do this instead:

     auto x = 1.to!string;

And you get:

Error: no property to for type int, perhaps import std.conv; is needed?

Clearly, something is not triggering, it should be the same suggestion 
for both cases. (FWIW, if this bug wasn't present, the gentlemen trying 
out D in the stream would have immediately imported std.conv and have 
been done)

-Steve
Oct 13 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2020 7:16 PM, Steven Schveighoffer wrote:

 void main()
 {
      auto x = to!string(1);
 }
 
 Error: template instance to!string template to is not defined
 
 BUT you do this instead:
 
      auto x = 1.to!string;
 
 And you get:
 
 Error: no property to for type int, perhaps import std.conv; is needed?
 
 Clearly, something is not triggering, it should be the same suggestion for
both 
 cases. (FWIW, if this bug wasn't present, the gentlemen trying out D in the 
 stream would have immediately imported std.conv and have been done)


A case can always be concocted to show this either way. The two expressions are 
equivalent, but they place different emphasis. I.e. the first places emphasis
on 
to being a function, the second places emphasis on to being a property.

There isn't winning with this.
Oct 13 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/14/20 12:05 AM, Walter Bright wrote:

 On 10/13/2020 7:16 PM, Steven Schveighoffer wrote:

 void main()
 {
      auto x = to!string(1);
 }

 Error: template instance to!string template to is not defined

 BUT you do this instead:

      auto x = 1.to!string;

 And you get:

 Error: no property to for type int, perhaps import std.conv; is needed?

 Clearly, something is not triggering, it should be the same suggestion 
 for both cases. (FWIW, if this bug wasn't present, the gentlemen 
 trying out D in the stream would have immediately imported std.conv 
 and have been done)


 
 A case can always be concocted to show this either way. The two 
 expressions are equivalent, but they place different emphasis. I.e. the 
 first places emphasis on to being a function, the second places emphasis 
 on to being a property.


You might be missing the fact that when I call a function as a function, 
and not a method, it doesn't suggest any imports.

This problem doesn't happen with writeln:

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

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

I expect the compiler to suggest an import of std.conv when I use `to` 
in the *same way*.


 There isn't winning with this.


I don't have any idea what you mean. You mean, the feature to suggest 
imports is useless? There's no way to fix it?

Here's a full bug report: https://issues.dlang.org/show_bug.cgi?id=21308

-Steve
Oct 14 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2020 8:32 AM, Steven Schveighoffer wrote:

 On 10/14/20 12:05 AM, Walter Bright wrote:

 There isn't winning with this.


 I don't have any idea what you mean.


It's stepping on a ripple in a carpet. It doesn't flatten the carpet, it just 
shifts the ripple to another spot.
Oct 14 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/14/20 4:27 PM, Walter Bright wrote:

 On 10/14/2020 8:32 AM, Steven Schveighoffer wrote:

 On 10/14/20 12:05 AM, Walter Bright wrote:

 There isn't winning with this.


 I don't have any idea what you mean.


 
 It's stepping on a ripple in a carpet. It doesn't flatten the carpet, it 
 just shifts the ripple to another spot.


Walter, there's a bug in the compiler code that suggests an import for a 
symbol such that in certain cases when you use the symbol and that 
symbol isn't defined, it doesn't suggest the import. It doesn't suggest 
anything. It doesn't shift to another spot. If you fix the bug, it 
should always suggest the import.

-Steve
Oct 15 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2020 5:56 AM, Steven Schveighoffer wrote:

 Walter, there's a bug in the compiler code that suggests an import for a
symbol 
 such that in certain cases when you use the symbol and that symbol isn't 
 defined, it doesn't suggest the import. It doesn't suggest anything. It
doesn't 
 shift to another spot. If you fix the bug, it should always suggest the import.


I don't agree that suggesting a global function for a .property is the most 
useful hint.

It's clearly a subjective opinion. But eventually there will be another "bug" 
report about why the hint is obviously wrong. That's par for the course
whenever 
the compiler makes a suggestion about a fix.
Oct 16 2020
parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Friday, 16 October 2020 at 07:09:39 UTC, Walter Bright wrote:

 On 10/15/2020 5:56 AM, Steven Schveighoffer wrote:

 Walter, there's a bug in the compiler code that suggests an 
 import for a symbol such that in certain cases when you use 
 the symbol and that symbol isn't defined, it doesn't suggest 
 the import. It doesn't suggest anything. It doesn't shift to 
 another spot. If you fix the bug, it should always suggest the 
 import.


 I don't agree that suggesting a global function for a .property 
 is the most useful hint.

 It's clearly a subjective opinion. But eventually there will be 
 another "bug" report about why the hint is obviously wrong. 
 That's par for the course whenever the compiler makes a 
 suggestion about a fix.


It seems you missed one crucial point here: the suggestion to 
import std.conv
*does* happen when invoked as 1.to!string, but *not* when invoked 
as to!string(1). It's already doing what you say is not the most 
useful hint, and failing to give a hint when to!string is invoked 
as a function call.

unittest {
     // template instance to!string template to is not defined
     auto x = to!string(1);

     // no property to for type int, perhaps import std.conv; is 
needed?
     auto y = 1.to!string;
}

--
   Simen
Oct 16 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 12 October 2020 at 20:46:07 UTC, Steven Schveighoffer 
wrote:


 What do you mean? Just add "to" : "std.conv". Is there a 
 problem with it?


It's already in the list [1], it's been there for two years. 
Unfortunately it's not that simple. The current implementation is 
a very simple mapping of a name to an import. What if there are 
multiple module level symbols with the same name in Phobos or 
druntime? Then the compiler will be wrong in some of those cases. 
Also, take this for example:

auto too(T, U)(U value)
{
     return value;
}

void main()
{
     auto a = 3.to!string;
}

This will result in a compile error:

Error: no property `to` for type `int`, perhaps `import 
std.conv;` is needed?

Obviously I meant to call the function `too` in the same module. 
Not `std.conv.to`.

[1] 
https://github.com/dlang/dmd/blob/aef4ac2a0901e4f2bf6cefe4c69a9c4c22cce76d/src/dmd/imphint.d#L78

--
/Jacob Carlborg
Oct 13 2020
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2020 1:31 AM, Jacob Carlborg wrote:

 Then the compiler will be wrong in some of those cases. 


At some point it's necessary to just accept how it works, because the compiler 
cannot read your mind and cannot know with certainty your intent. If the 
compiler could always discern what you meant, it wouldn't need to issue an
error 
message at all.

The spell checker is simple and is surprisingly effective, guessing right more 
than 50% of the time for me. The import hinter does even better.

If there's fault here, it is not in the checker or the hinter, it's in the 
choice of an extremely common word "to" in the library.
Oct 13 2020
prev sibling next sibling parent Andrew Edwards <edwards.ac gmail.com> writes:
On Tuesday, 13 October 2020 at 08:31:34 UTC, Jacob Carlborg wrote:

 On Monday, 12 October 2020 at 20:46:07 UTC, Steven 
 Schveighoffer wrote:

 auto too(T, U)(U value)
 {
     return value;
 }

 void main()
 {
     auto a = 3.to!string;
 }

 This will result in a compile error:

 Error: no property `to` for type `int`, perhaps `import 
 std.conv;` is needed?

 Obviously I meant to call the function `too` in the same 
 module. Not `std.conv.to`.


By revisiting the line of offending code, it would be immediately 
apparent as to what was intended—assuming, of course, that the 
person encountering the error is, in fact, the author of the 
code. The suggestion, therefore, is not entirely useless. I can 
easily infer from it what needs to be corrected. What would 
improve the situation is providing context along with the error 
message:

Error: no property `to` for type `int`, perhaps `import
std.conv;` is needed?

    auto a = 3.to!string;
               ^--------
Oct 13 2020
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/13/20 4:31 AM, Jacob Carlborg wrote:

 On Monday, 12 October 2020 at 20:46:07 UTC, Steven Schveighoffer wrote:
 

 What do you mean? Just add "to" : "std.conv". Is there a problem with it?


 
 It's already in the list [1], it's been there for two years. 


Wait, why doesn't it work?

void main()
{
     auto x = to!string(1);
}

onlineapp.d(3): Error: template instance to!string template to is not 
defined


 Unfortunately it's not that simple. The current implementation is a very 
 simple mapping of a name to an import. What if there are multiple module 
 level symbols with the same name in Phobos or druntime? Then the 
 compiler will be wrong in some of those cases. Also, take this for example:
 
 auto too(T, U)(U value)
 {
      return value;
 }
 
 void main()
 {
      auto a = 3.to!string;
 }
 
 This will result in a compile error:
 
 Error: no property `to` for type `int`, perhaps `import std.conv;` is 
 needed?


If you look at the "New to Dlang" stream, what happens is it says "Did 
you mean `No`?". So literally what you are asking for it to do (and it 
does do), causes about 30 minutes of fruitless searching. Whereas if it 
had said "perhaps `import std.conv;` is needed?", I think a more 
favorable review might have been the result.

I tested it some more.

1.to!string => Suggests import std.conv
to!string(1) => No template named to.

This seems like a bug to me.

-Steve
Oct 13 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 12 October 2020 at 20:11:51 UTC, Walter Bright wrote:

 On 10/12/2020 11:17 AM, Steven Schveighoffer wrote:

 As I understand it, these functions to import mappings are 
 hard coded in the compiler.


 https://github.com/dlang/dmd/blob/master/src/dmd/imphint.d

 Of course, this won't work for "to" since there are multiple 
 declarations of "to" in Phobos (shoot me now).


I think making that list dynamic rather than hard coded might be 
it. But for add "to" -> "std.conv.to"
Oct 13 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2020 12:14 AM, aberba wrote:

 I think making that list dynamic rather than hard coded might be it.


Not worth the complexity.
Oct 13 2020
prev sibling next sibling parent reply Andrew Edwards <edwards.ac gmail.com> writes:
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.


I don't even understand the issue here. If I am having an issue 
with something written to!string, why on earth would I search for 
to? I would simply search for to!string because that's where my 
problem lies. Which, by the way, provides the solution to my 
problem in the first hit of the returned results.
Oct 12 2020
parent Andrew Edwards <edwards.ac gmail.com> writes:
On Tuesday, 13 October 2020 at 05:22:52 UTC, Andrew Edwards wrote:

 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.


 I don't even understand the issue here. If I am having an issue 
 with something written to!string, why on earth would I search 
 for to? I would simply search for to!string because that's 
 where my problem lies. Which, by the way, provides the solution 
 to my problem in the first hit of the returned results.


There will never be a place in code where to is used without 
being instantiated.

to!
to!(
to!string
to!int
to!double
to!float
to!char
to!long

In every std.conv is the first result returned.
Oct 12 2020
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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);


I Ctrl-K'ed (i.e. went to the search bar in Firefox) and typed 
"site:dlang.org to". The first hit was the documentation for 
std.conv.to.

This was on Google. If anything this says more about duckduckgo.
Oct 14 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2020 3:44 AM, Atila Neves wrote:

 It's not even searchable on the DLang site (e.g. using site:dlang.org on 
 DuckDuckGo);


 
 I Ctrl-K'ed (i.e. went to the search bar in Firefox) and typed "site:dlang.org 
 to". The first hit was the documentation for std.conv.to.
 
 This was on Google. If anything this says more about duckduckgo.



I read that Google customizes searches to the individual based on their past 
behavior. So what other people see when they search is not what you're likely
to 
see, especially if Google knows you hang out on dlang.org.
Oct 14 2020
next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 14 October 2020 at 20:29:48 UTC, Walter Bright 
wrote:

 On 10/14/2020 3:44 AM, Atila Neves wrote:

 It's not even searchable on the DLang site (e.g. using 
 site:dlang.org on DuckDuckGo);


 
 I Ctrl-K'ed (i.e. went to the search bar in Firefox) and typed 
 "site:dlang.org to". The first hit was the documentation for 
 std.conv.to.
 
 This was on Google. If anything this says more about 
 duckduckgo.



 I read that Google customizes searches to the individual based 
 on their past behavior. So what other people see when they 
 search is not what you're likely to see, especially if Google 
 knows you hang out on dlang.org.


I don't use Google for anything but it comes up first for me. 
Anyone using the search bar in the upper right of this page will 
have it as the first result. It's the first result on Bing. It's 
the fifth result on DDG.
Oct 14 2020
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/14/20 4:29 PM, Walter Bright wrote:

 On 10/14/2020 3:44 AM, Atila Neves wrote:

 It's not even searchable on the DLang site (e.g. using site:dlang.org 
 on DuckDuckGo);


 I Ctrl-K'ed (i.e. went to the search bar in Firefox) and typed 
 "site:dlang.org to". The first hit was the documentation for std.conv.to.

 This was on Google. If anything this says more about duckduckgo.


 
 
 I read that Google customizes searches to the individual based on their 
 past behavior. So what other people see when they search is not what 
 you're likely to see, especially if Google knows you hang out on dlang.org.


Just open a new anonymous window to get non-personalized searches.
Oct 14 2020
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 14 October 2020 at 20:29:48 UTC, Walter Bright 
wrote:

 On 10/14/2020 3:44 AM, Atila Neves wrote:

 It's not even searchable on the DLang site (e.g. using 
 site:dlang.org on DuckDuckGo);


 
 I Ctrl-K'ed (i.e. went to the search bar in Firefox) and typed 
 "site:dlang.org to". The first hit was the documentation for 
 std.conv.to.
 
 This was on Google. If anything this says more about 
 duckduckgo.



 I read that Google customizes searches to the individual based 
 on their past behavior. So what other people see when they 
 search is not what you're likely to see, especially if Google 
 knows you hang out on dlang.org.


Correct - and it'd be likely of anyone else searching for that as 
well.
Oct 16 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 12 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 12 2020
parent Jacob Carlborg <doob me.com> writes:
On Monday, 12 October 2020 at 20:06:31 UTC, Walter Bright wrote:

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


According to Clean Code, that's true for variable names. But for 
functions, it's the opposite. Because, the more global a function 
is, the more general it is (or ought to be). The more local a 
function is, the more specialized it is.

--
/Jacob Carlborg
Oct 13 2020
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 12 October 2020 at 19:35:37 UTC, Walter Bright wrote:


 "Yes" and "No" are also poor names, the latter is hopelessly 
 ungreppable.


I agree that `Yes` and `No` are bad names.


 Furthermore, they are just redundant to "true" and "false". 
 They never should have been put in Phobos.


But the problem with `true` and `false` is that it's difficult to 
know the meaning at the call site. That can be solved with a 
custom enum for each function, that allows for better names. Or 
with named arguments (which D doesn't support yet). But unless 
you're using Swift or Objective-C, there's nothing that force you 
do use named arguments on the call site.

--
/Jacob Carlborg
Oct 13 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2020 1:08 AM, Jacob Carlborg wrote:

 Or with named arguments (which D doesn't 
 support yet).


That is the solution, and D will.


 But unless you're using Swift or Objective-C, there's nothing that 
 force you do use named arguments on the call site.


That's right, and we aren't going to add it. The facility of named arguments is 
there when people want to use it.
Oct 13 2020
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 3:35 PM, Walter Bright wrote:

 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.


git grep '\Wto!'

yields the uses.

git grep '\Wto('

yields the definitions.


 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.


git grep '\WNo\.'

yields the uses.

Flag, Yes, and No were introduced to avoid this antipattern:

https://www.informit.com/articles/article.aspx?p=1392524

https://medium.com/ amlcurran/clean-code-the-curse-of-a-boolean-parameter-c237a830b7a3

https://understandlegacycode.com/blog/what-is-wrong-with-boolean-parameters/
Oct 13 2020
prev sibling next sibling parent reply Andrew Edwards <edwards.ac gmail.com> writes:
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 and it took them a long time to figure out how 
 to use a to!string expression. :/

 Ali


I'm far from being the sharpest tool in the shed but a little 
common sense could have helped them quite a bit. Like knowing I'm 
searching for a particular construct in the D Language, I'd 
prefix my searches with dlang. In this particular case "dlang 
to!string" pulled up the solution as the first hit of the 
returned results.

But to be honest, given a website with a search bar, I would 
never return to Google to search for anything I'd expect to find 
on that site. Or if I did, at the very least, I'd prefix my 
searches with site:dlang.org.

Which reminds me, we need to include a search bar on 
tutor.dlang.org. It should point to the library by default and 
have the option to change to other sections of the site similar 
to the search feature on other pages on the site.

Also, there are code samples throughout the site that provide a 
run button but does not import the appropriate modules to ensure 
successful compilation. I think that hurts more than watching 
those two guys pretending to be newbies to programming.

Listening to the conversation those two were having, it is clear 
that they've been programming for a while. Maybe not in D, but 
they are actual programmers. This presentation caused some 
frustration since they were trying to act like they knew 
absolutely nothing about programming and did things I don't think 
even the most novice of programmers would do.
Oct 12 2020
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 13 October 2020 at 05:11:08 UTC, Andrew Edwards 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 and it took them a long time to figure out how 
 to use a to!string expression. :/

 Ali


 I'm far from being the sharpest tool in the shed but a little 
 common sense could have helped them quite a bit. Like knowing 
 I'm searching for a particular construct in the D Language, I'd 
 prefix my searches with dlang. In this particular case "dlang 
 to!string" pulled up the solution as the first hit of the 
 returned results.

 But to be honest, given a website with a search bar, I would 
 never return to Google to search for anything I'd expect to 
 find on that site. Or if I did, at the very least, I'd prefix 
 my searches with site:dlang.org.

 Which reminds me, we need to include a search bar on 
 tutor.dlang.org. It should point to the library by default and 
 have the option to change to other sections of the site similar 
 to the search feature on other pages on the site.

 Also, there are code samples throughout the site that provide a 
 run button but does not import the appropriate modules to 
 ensure successful compilation. I think that hurts more than 
 watching those two guys pretending to be newbies to programming.

 Listening to the conversation those two were having, it is 
 clear that they've been programming for a while. Maybe not in 
 D, but they are actual programmers. This presentation caused 
 some frustration since they were trying to act like they knew 
 absolutely nothing about programming and did things I don't 
 think even the most novice of programmers would do.


Indeed it was infuriating to see these clowns even finding the 
right pages to their problems but not noticing because they 
didn't bother to actually read the pages they consulted. RTFM! 
(how to download the compiler? maybe by clicking on the 
"download" menu entry, you fool. What are these 3 compilers? 
Maybe read the description in front on them, you dummy)
Clicking and copy pasting randomly without even trying to read 
stuff is not good process. It was a wonder that they even came as 
far as they did when seeing their broken methodology.
We should also be wary to not cater too much on making the pages 
fool proof, it will only breed better fools.
Sorry if it is a bit inflammatory but it was annoying to see 
these two guys fumbling around like idiots where 30 seconds of 
reading would have solved their issues. If that is the new normal 
of post millenial programmers then may God (and I'm an atheist) 
have mercy on us when all boomers have retired.
Oct 13 2020
prev sibling next sibling parent reply Ogi <ogion.art gmail.com> writes:
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 and it took them a long time to figure out how 
 to use a to!string expression. :/


When I try to search for “dlang to” in Google, the first result 
points to std.conv.to page. Their problem was that their queries 
looked like “dlang to template”, “dlang import to module” etc. 
Search engines are doing a good job at searching “unsearchable” 
things unless you pollute your query with irrelevant words.

Keywords like “to” and “yes” are perfectly fine. It’s not D’s 
fault that some people don’t know how to use the internet.
Oct 13 2020
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/13/20 7:53 AM, Ogi 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 and it took them a long time to figure out how to use a 
 to!string expression. :/


 
 When I try to search for “dlang to” in Google, the first result points 
 to std.conv.to page. Their problem was that their queries looked like 
 “dlang to template”, “dlang import to module” etc. Search engines are 
 doing a good job at searching “unsearchable” things unless you pollute 
 your query with irrelevant words.


Also: most of the time people want to convert something to something 
else so they'd search for dlang convert. All of the first page results 
are relevant, with std.conv at the top.
Oct 13 2020
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:

 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.


They are right next to each other

https://www.dvorak-keyboard.com/

But I'd never make that mistake :)
Oct 13 2020
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/13/20 7:27 AM, Jesse Phillips wrote:

 On Monday, 12 October 2020 at 17:04:01 UTC, Ali =C3=87ehreli wrote:

 I think Levenstein distance is applied there but to suggest that a=20
 human mistook 'to' as 'No' is funny. :) Considering keyboard layouts, =





 it can't be a typo either.


=20
 They are right next to each other
=20
 https://www.dvorak-keyboard.com/
=20
 But I'd never make that mistake :)


I use Dvorak too. ;)

Ali
Oct 13 2020
prev sibling next sibling parent reply claptrap <clap trap.com> writes:
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?
Oct 12 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 12 2020
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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?"

 -Steve


I suspect this old bug report is related, and there's an 
explanation for what would have to change in order to fix it.

https://issues.dlang.org/show_bug.cgi?id=5621
Oct 13 2020