typeof() used where a explicit type is expected

[busterwood]

I would like to declare fields, parameters and variable using typeof, which reduces duplication of type declarations, addtionally makes refactoring easier.
For example:

class Customer {
    public int Id { get; set; }
    public List<Order> Orders { get; set; }
    ...
}

interface IRepository {
    Customer Get(typeof(Customer.Id) id);
    typeof(Customer.Orders) ReloadOrders(typeof(Customer.Id) id);
}

Basically, why not allow typeof(...) to be used anywhere a type is expected by the compiler?

Another example, casting:

public IEnumerable<ContactJson> ItemsSource {
    get {
        return (typeof(this.ItemsSource))GetValue(ItemsSourceProperty);
    }
    set {
        SetValue(ItemsSourceProperty, value);
    }
}

Note the use of (typeof(this.ItemsSource)) as the cast in the getter

[MkazemAkhgary]

which reduces duplication of type declarations, addtionally makes refactoring easier.

Can you prove your claim? you just proposed a new syntax. but you should compare that with alternative using current c# code.

In other words, I don't really get what you mean by duplication of type declarations and how your proposal is supposed to make refactoring easier. I don't get your examples either.

Note the use of (typeof(this.ItemsSource)) as the cast in the getter

whats the purpose of casting to type of ItemsSource? why not just cast to IEnumerable<ContactJson>?

And for Customer Get(typeof(Customer.Id) id);, why not simply write Customer Get(int id);?

[busterwood]

I guess the proposal is about removing duplication. If you declare that Customer.Orders is of type List<Order> then that should only be declared in one place, so it can be changed in one place. Declaring another method, for example List<Orders> ReloadOrders(int id); is duplication of both the type of Customer.Orders and the type of Customer.Id.

Oracle PL/SQL has a related feature, %TYPE attribute that allows you to declare a type to be the same as another thing (e.g. column)

[aluanhaddad]

It sounds like you want to reference the types of type members. Generics already provide this to a large extent. For example, a customer can implement

interface IOrderBearer
{
    IEnumerable<T> Orders { get; }
}

Of course this gets tedious very quickly if you want to map every property, but the only way to avoid that is to have structural types.

Structural types can be incredibly useful but alas, the CLR doesn't have such a concept which would make adding it to C# difficult for the same reason that adding intersection types and union types is difficult.

[DerpMcDerp]

typeof returns reflection information. I think you want a completely different operator like C++'s decltype rather than overloading typeof for this purpose.

Also, I think the last example would be better if you could do:

public IEnumerable<ContactJson> ItemsSource {
    get {
        return (decltype(return))GetValue(ItemsSourceProperty);
    }
}

which signals to the compiler to look at the return type. Or:

public IEnumerable<ContactJson> ItemsSource {
    get {
        return (decltype(var))GetValue(ItemsSourceProperty);
    }
}

which signals to the compiler to insert the proper cast for you.

[aluanhaddad]

I don't think its about casting. decltype is it good point of comparison but it doesn't cast in C++, it computes types.

[MkazemAkhgary]

Not always helpful but for single cs file, using alias maybe helpful.

using CustomerIdType= System.Int32;

Its not something I would do normally as long as I know that a type is never going to change.

but its there you can use it. (I may use it to shorten type names if actual type name is too long.)

would be nice if aliases could become public, that would address your problem too.

[AustinBryan]

Basically, why not allow typeof(...) to be used anywhere a type is expected by the compiler?

That's really your argument for a new feature, "why not?" For one, it's hard to read and is even longer to type, two, customer id could be double, int, float, short, byte, etc., I have no idea, so now you're just hiding that information from me.

It doesn't make things easier to read, because now I have to think and remember what that certain type was, which is just unnecessary cognitive load and if I'm trying to refactor something I don't want to have to try and remember what type I was using.

[TonyValenti]

I've recently run into situations where this would be really useful as well. Something like this can make code refactoring-safe as you can change a type in one place and have it ripple through your source.

[uygary]

First of all, the way it currently is is not "duplication of type declarations." We're literally talking about declaring the type information of 2 different members on 2 separate objects. You may say it's explicit, and I'd gladly agree with that, but you can't really say it's duplication.
And that actually relates to the main point I want to make: Scattering contracts/type definitions across separate files/types is, in my humble opinion, a horrible idea. It makes the code difficult to read and difficult to search.
Not to mention the fact that this would partially replace the coupling between contracts and underlying models with the coupling between contracts and otherwise unrelated models that refer to the underlying models, which seems dangerous and hard to maintain to me in terms of refactoring.

If one wants such a coupling between models, one should introduce their own domain models to hold data, so that they'll only need to modify the contents of their CusromerId classes/structs. The benefit of this approach is: Code-smell will be contained to the particular repository in question, instead of being propagated throughout the ecosystem via the introduction of a language feature.