User defined properties signatures

[Idan Arye via Digitalmars-d-learn]

On Tuesday, 21 April 2015 at 13:53:15 UTC, Dicebot wrote:
> On Tuesday, 21 April 2015 at 13:27:48 UTC, Marc Schütz wrote:
>> On Monday, 20 April 2015 at 20:22:40 UTC, Jonathan M Davis 
>> wrote:
>>> There may be languages out there which take the the return 
>>> type into account
>>> when overloading, but I've never seen one.
>>
>> Rust does, as far as I know.
>
> And this is incredibly frustrating approach that harms both 
> readability and maintainability (you can't cut/paste RHS of an 
> expression anymore without additional changes to the context). 
> I have actually mentioned that when doing "first impressions" 
> post about Rust.

Considering ownership and all the compile-time checks Rust does, 
I'd say you generally can't just cut/paste any part of an 
expression, or even whole statements, and expect it to just work. 
Also, in Rust's case this doesn't really count as overloading but 
as a template instantiation.



BTW, the scope of this feature is much wider. Take a look at the 
channels example from the online book: 
http://doc.rust-lang.org/1.0.0-beta.2/book/concurrency.html#channels. 
Rust's type system is super strict, but mpsc::channel() doesn't 
specify the type of the stuff sent into the channel, and yet it 
is set correctly for both tx and rx.

What's happening here is this:

1) tx.send receives an argument(or doesn't receive an argument), 
which lets the compiler know what the type of tx is.
2) Now that the compiler knows what the type of tx is, it knows 
what the type of mpsc::channel is, because it needs to match tx.
3) At this point, type inferring rx's type is straightforward.

Now, Rust can do this because it has a super-strict type system. 
For D to be able to do this, it would have to completely reinvent 
it's type system, discarding many of it's idioms along the way, 
resulting at quite a different language.