[Proposal] Member access operator

[egortech]

Currently, there is not able to set custom member access routing that would be useful for wrapper type like we already have in Nullable operator ?., I proposed to add and allow to overload such operator for given type T that wrap type TWrap:

public static TWrap operator*(T value)
public static TWrap operator->(T value)

For example, we have in Framework type Lazyproperty Value that provide value of type T, if we want to access some member or call function M of T currenly we should write, for example:

var f = new Lazy<Point>(i => new Point(0, 0));
var length = Math.Sqrt(Math.Pow(f.Value.X + f.Value.Y, 2));
var p = f.Value;

With proposed operator it can be written like:

var f = new Lazy<Point>(i => new Point(0, 0));
var length = Math.Sqrt(Math.Pow(f->X + f->Y, 2));
var p = *f;

We already have such semantic for a pointer type, so it can be expanded for a custom type, too.

Sorry if I duplicated a similar proposal somehow.

[DaZombieKiller]

This would be an abuse of operator overloading (imo) and only really serves to make the code less clear. * and -> are synonymous with pointers, and suddenly having them appear in safe code with non-pointer values would be very confusing, and probably syntactically ambiguous in some situations.

[egortech]

It can be used in WeakReference scenario or another custom reference-like type, for example in the implementation of some sort of smart pointer like in C++.

[CyrusNajmabadi]

It can be used in WeakReference scenario or another custom reference-like type

Those are the last place i would ever want to overload these operators. I absolutely do not want to treat the weak-ref the same as teh wrapped type.

[ActivistInvestor]

I'm recycling this because it is something that offers key functionality that makes C++ much easier to deal with. Member access operator overloading is something that does not exist solely for the sake of smart pointers.

However, instead of overloading the member access operator, I would like to explore something that might offer the functional equivalent. Which involves nothing more than extending the use of the 'this' keyword currently used to declare/define indexers, which is merely one kind of default property. This concept was in-part inspired by Pascal's implements keyword, which allows the value of published property to provide the implementation of an interface declared on the containing type. The conceptual extension of the 'this' keyword as outlined below, offers that same functionality in addition to allowing a 'wrapper' type to impersonate the type it wraps.

In the example below, note the use of 'this' in the first type, which enables a functional equivalent (to some extent) of an overloadable member access operator, that would support Proxy/Adapter-type patterns:

public class Wrapper<T> where T : new()
{
   protected readonly T wrapped;

   public Wrapper(T? wrapped = default)
   {
      this.wrapped = wrapped ?? new T();
   }

   //////////////////////////////////
   /// Note the use of 'this' here:

   public T this => wrapped;
}

public class Person
{
   public string? Name { get; set; }
   public int Id { get; set; }
}

public class WrappedPersonExample
{
   public void Main()
   {
      Person person = new Person
      {
         Name = "Abe Lincoln",
         Id = 1
      };

      // an instance of Wrapper<Person>:
      
      var wrapped = new Wrapper<Person>(person);

      // that can be accessed as if it were an 
      // instance of the wrapped type:
      
      string name = wrapped.Name;
      int id = wrapped.Id;
   }
}

Using an extended 'this' keyword to delegate the implementation of an interface:

public interface IPathResolver
{
   void ResolvePath(Type type);
}

public interface IDomainResolver
{
   void ResolveDomain(IPathResolver pathResolver)
}

public class PathResolver : IPathResolver
{
   public void ResolvePath(Type type)
   {
      /// Implementation of ResolvePath()
   }
}

public class DomainResolver : IDomainResolver
{
   public void ResolveDomain(IPathResolver)
   {
      /// Implementation of ResolveDomain()
   }
}

This example uses an extended 'this' to delegate multiple interfaces:

public class Resolver : IPathResolver, IDomainResolver
{
   PathResolver pathResolver = new PathResolver(this);
   DomainResolver domainResolver = new DomainResolver(this);

   public IPathResolver this => pathResolver;
   public IDomainResolver this => domainResolver;   
}

[Drahsid]

My motivation for this suggestion came from a project that I am working on with some friends of mine, where we are managing an emulator in dotnet, and allowing developers to interface with the emulator through plugins that are also written in dotnet. We encountered a problem where there is no sane syntax for interfacing with the emulated system's memory using structs when the emulated system has a different endianess, the closest we could get to this is forcing developers to use properties for every structure field, which in our circumstance is unacceptable syntax.

As an example, I am specifically trying to avoid asking develoeprs to use the following syntax:

[StructLayout(LayoutKind.Explicit), EmulatedStruct]
struct Camera {
    [FieldOffset(0x50)] public Vector3 Position { get; set; }
};

... 

Camera camera = new Camera(0x1248);
var pos = camera.Position; // we must make an additional variable since we cannot assign to a property
pos.X *= 10.0f;
camera.Position = pos;

And I additionally want to avoid the .Value syntax mentioned in the original proposal:

Camera camera = new Camera(0x1248);
camera.Position.Value.X *= 10.0f;

Both of these solutions are significantly more unclear and would end up having either more implementation hell, or overhead than a smart pointer alternative.

That all said, I absolutely do not want to see smart pointers, or the overloading of the * and -> operators in safe code. I would be to make something which is very explicitly unsafe, and/or only functional with actual pointers/pointer-types.

My purpose for wanting this feature is so that I can give my plugin developers memory safe, endian-correct ways to interface with memory, and clean syntax.

[colejohnson66]

What is Vector3? System.Numerics.Vector3 does not have a "Value" property. If this is a custom defined type, you can add an overload for the * operator on Vector3. Then camera.Position *= 10.0f would work.