Go calls methods through pointers using ., and allows for method declarations
on pointers as well as structs. It also allows for embedding one struct in
another, and method resolution will search the embedded struct if the embedding
struct doesn't have a match. This seems to be working well there. I don't see
why it can't work for Rust.
-Kevin
On Aug 5, 2013, at 6:16 PM, Gábor Lehel <illiss...@gmail.com> wrote:
> I agree that overloadable * would be very desirable for smart
> pointers. I also really like the interaction with newtypes. Is it
> still the plan (from the GC thread) to push all mutability into Cell?
> Would that interact with this proposal in any way (e.g. to allow
> mutating through * in some cases)?
>
> The method lookup part of it feels too magical. What if both the
> pointer and the pointee have a method with the same name? In general,
> how can you tell whether you're calling a method on the "pointer" or
> the "pointee"? The reason using the dot both for calling methods
> directly and for calling them through pointers worked so far is that
> pointers didn't have methods. Disambiguating this situation is what
> C++ has the -> operator for: would it be so bad to adopt it? With a
> simple desugaring to (*foo).bar it would remove the magic, and the
> common fields use case would also continue to work with a different
> syntax. I'm guessing this is another of those decisions that was
> discussed and settled a long time ago. Is there any other language
> with universal dot notation where custom smart pointers are common?
>
> On Tue, Jul 30, 2013 at 7:28 AM, Patrick Walton <pwal...@mozilla.com> wrote:
>> Currently, newtype structs automatically dereference to the value they
>> contain; for example:
>>
>> struct MyInt(int);
>> fn main() {
>> let x = MyInt(3);
>> printfln("1 + 2 = " + x.to_str()); // prints "1 + 2 = 3"
>> }
>>
>> This behavior is sometimes undesirable, as Brian often points out. Haskell
>> allows behavior similar to this to be controlled on an opt-in basis with
>> `GeneralizedNewtypeDeriving`.
>
> I think these are subtly different. Rust is automatically unwrapping
> the newtype when calling a method on it, while Haskell is
> automatically generating requested trait impls based on the ones for
> the inner type. But not vice versa: for functions other than those on
> derived traits/classes Haskell still requires manual unwrapping, and
> Rust doesn't consider the newtype to impl traits just because the
> inner type does. Allowing overloads of */-> on newtypes and
> GeneralizedNewtypeDeriving would be independently useful features
> (just be careful when mixing the latter with associated types).
>
> --
> Your ship was destroyed in a monadic eruption.
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
