I must be going crazy, but I thought this behavior was implemented in D.

Is this just something someone proposed as an enhancement or is it real?

int myfunc(int x)
{
   return x + 5;
}

int test()
{
  int m = 10;
  return m.myfunc;  // implicitly knows that it should call myfunc(m)
}

I can't find anywhere that this is mentioned, but I swear I read it somewhere, either in a newsgroup post or the D specs.

-Steve

Steven Schveighoffer wrote:
> I must be going crazy, but I thought this behavior was implemented in D.
> 
> Is this just something someone proposed as an enhancement or is it real?
> 
> int myfunc(int x)
> {
>    return x + 5;
> }
> 
> int test()
> {
>   int m = 10;
>   return m.myfunc;  // implicitly knows that it should call myfunc(m)
> }
> 
> I can't find anywhere that this is mentioned, but I swear I read it somewhere, either in a newsgroup post or the D specs.
> 
> -Steve 
> 
> 

This currently works only for the array types. It was proposed to generalize it for all types.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

"Kirk McDonald" wrote
>
> This currently works only for the array types. It was proposed to generalize it for all types.

Kirk,

Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.

-Steve

Steven Schveighoffer wrote:
> "Kirk McDonald" wrote
>> This currently works only for the array types. It was proposed to generalize it for all types.
> 
> Kirk,
> 
> Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.

That makes me nervous too.  It's hard enough having to search up the inheritance hierarchy to find out where 'bar' is implemented when you run across "foo.bar()".  But if you also have to potentially examine *every* import as well... oh boy.

Another option would be to make them non-importable.  So then you know it's either defined somewhere in the inheritance chain or in the local file.  But that would probably just lead to people working around it using mixin(import(...)).

Apparently other languages have this feature though.  I'm curious how they avoid the maintenance nightmare.

--bb

Bill Baxter wrote:
> Apparently other languages have this feature though.  I'm curious how they avoid the maintenance nightmare.

With good IDEs. (If they solve it at all, that is.)

I would like to see it work with static imports, though:

static import foo;
int i;
int j = i.foo.frob;

You're far less likely to confuse that than if you had to dynamically (?) import frob to use the member syntax.

Steven Schveighoffer Wrote:

> 
> "Kirk McDonald" wrote
> >
> > This currently works only for the array types. It was proposed to generalize it for all types.
> 
> Kirk,
> 
> Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
> 
> -Steve
> 

Use a semantic-aware IDE.

Bill Baxter wrote:
> Steven Schveighoffer wrote:
> 
>> "Kirk McDonald" wrote
>>
>>> This currently works only for the array types. It was proposed to generalize it for all types.
>>
>>
>> Kirk,
>>
>> Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
> 
> 
> That makes me nervous too.  It's hard enough having to search up the inheritance hierarchy to find out where 'bar' is implemented when you run across "foo.bar()".  But if you also have to potentially examine *every* import as well... oh boy.
> 
> Another option would be to make them non-importable.  So then you know it's either defined somewhere in the inheritance chain or in the local file.  But that would probably just lead to people working around it using mixin(import(...)).
> 
> Apparently other languages have this feature though.  I'm curious how they avoid the maintenance nightmare.
> 
> --bb

This is why I am a big, big fan of selective imports (and to a lesser extent static imports): You always know exactly what you are importing and from where.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Steven Schveighoffer wrote:
> "Kirk McDonald" wrote
>> This currently works only for the array types. It was proposed to generalize it for all types.
> 
> Kirk,
> 
> Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
> 
> -Steve

Heaven knows we don't have the exact same problem with free functions, since you can always tell where they're coming from.  And hell, you *always* have the ability to modify a class or struct's definition, so there's no reason to ever create a free function!

	-- Daniel


P.S.  For those that don't know me very well: :P

Daniel Keep wrote:
> 
> Steven Schveighoffer wrote:
>> "Kirk McDonald" wrote
>>> This currently works only for the array types. It was proposed to generalize it for all types.
>> Kirk,
>>
>> Thanks, that is where I read it.  For some reason I couldn't find it.  I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :)  Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
>>
>> -Steve 
> 
> Heaven knows we don't have the exact same problem with free functions,
> since you can always tell where they're coming from.  And hell, you
> *always* have the ability to modify a class or struct's definition, so
> there's no reason to ever create a free function!
> 
> 	-- Daniel
> 
> 
> P.S.  For those that don't know me very well: :P

Point taken.  If you're sloppy about namespaces to begin with this will just make it worse.  If you're tidy, it'll be no problem because every such function you're using will have to be explicitly imported into the namespace.  Yet another reason static import should be the default.

--bb