C# next - Future request - useType()

[deadmann]

Today with so many architect, lot of stuff rely on each other, and some of them are repeated, and changing them requires lot of changes,... what I'm going to say may have many usage through time, but I came up with it when i was working on repository interface...

Here's the scenario:

I have a class

public class X {
    public int Id {get;set;}
    public string Name{get;set;
}

and then I have a base repository

public BaseRepository<TEntity, TId> {
    //blah blah blah
}

and then I have a repository for that class

public class XRepository : BaseRepository<X, int> {
    //foo bar
}

the issue here is if I get to change that entity ID type to say long, I have to update all interfaces and repository of that type too, aside from any layer that may been built upon it.
So I suggest a new feature "useType", i rather name it typeof, but it's already in use and as suggested it returns a Type object, so here i named it useType, or anything that came to mind with better understanding

and then, I suggest to rewrite the XRepository as following

public class XRepository : BaseRepository<X, useType(X.Id)> {
    //foo bar
}

It also can simplify and come to aid, in many other scenario, when you need to use a type directly with generics, with reflections, within many other things out there.

[svick]

This looks like a duplicate of #1294, only with different syntax.

[HaloFour]

This proposal adds the ability to reference the other type in generic type arguments as well. I wonder if associated types would satisfy that use case.

[deadmann]

This looks like a duplicate of #1294, only with different syntax.

Yeah it seems alike it will look at the existing

[deadmann]

This proposal adds the ability to reference the other type in generic type arguments as well. I wonder if associated types would satisfy that use case.

I'm not sure exactly,
But in case we have

public interface IGenericInterface<TDesiredType> {
    public TDesiredType DesiredProperty {get;set;}
}

we can hope to have this:

public interafce IInheritedInterface : IGenericInterface<int>{
}

and

public interface UseInterface<useType(IInheritedInterface.DesiredProperty)>{ //1
    public useType(IInheritedInterface.DesiredProperty) Data{get;set;} //2
}

but not this:

public interface INotAllowed<useType(IGenericInterface.DesiredProperty)>{}

this should generate an error such as:

The INotAllowed uses a generic type which is not defined...

or

The X property point to a property with no valid type.

still it should be allowed if: we are referencing an instance :

public class InheritedClass:InheritedInterface{}

InheritedClass newInstance = new InheritedClass();
var instance = (IGenericInterface)newInstance;
useType(instance.DesiredProperty) variable = instance.DesiredProperty;

---

Also it can be expanded to method too.

1. useType(X.MyMethod) // should use the return type of MyMethod (if it is not)
   extra feature:
2. useType(X.MyMethod, 2) //use second parameter of the function
3. use Type(X.MyMethod, "data") //use parameter type named "data" in the signature
4. useType(X.MyMethod, m=>m.Id) //use parameter found using fluent, extra work, but it can be tracked better for automatic refactoring.

[huoyaoyuan]

I think what you want should be #1695 .

[deadmann]

I think what you want should be #1695 .

I don't feel like it, it seem to serve some of the purposes but in term of adding additional complexity to the reader.

although #1695 is nice feature to have, it's a bit off toward the topic I'm talking about,
#1294 has more common scenario

[erik-kallen]

I like the idea. TypeScript, for example, has the feature. I think, though, that the typeof keyword could be reused, it cannot be used in a generic argument list today.

[nmarcel]

I like it, but with a better name: useTypeOf([source member]).
So, it would help to keep types synchonized between members that are related.

Consider the next usual business example:

public class ProductInternalModel
{
    public int Id { get; set; }
    public EAN BarCode { get; set; }
    public string Name { get; set; }
    public Currency Cost { get; set; }
    public Currency Price { get; set; }
}

public class ProductExposedViewModel
{
    public useTypeOf(ProductInternalModel.Id) Id { get; set; }
    public useTypeOf(ProductInternalModel.Name) Name { get; set; }
    public useTypeOf(ProductInternalModel.Price) SalePrice { get; set; }
}

This would avoid a lot of type mismatch exceptions.

[deadmann]

I like it, but with a better name: useTypeOf([source member]).
So, it would help to keep types synchonized between members that are related.

Consider the next usual business example:

public class ProductInternalModel
{
    public int Id { get; set; }
    public EAN BarCode { get; set; }
    public string Name { get; set; }
    public Currency Cost { get; set; }
    public Currency Price { get; set; }
}

public class ProductExposedViewModel
{
    public useTypeOf(ProductInternalModel.Id) Id { get; set; }
    public useTypeOf(ProductInternalModel.Name) Name { get; set; }
    public useTypeOf(ProductInternalModel.Price) SalePrice { get; set; }
}

This would avoid a lot of type mismatch exceptions.

the name is not an issue to me, but exactly it's too keep related stuff in sync, and also make intellisense and refactoring smarter

[deadmann]

I saw some people gave this feature thumbs down,... I wish to discuss why you think this feature is bad. and compare it's cons vs its pros

[theunrepentantgeek]

I saw some people gave this feature thumbs down

Well, since you asked nicely. 😁
Warning: Strong opinions ahead. This is my experience, my opinions. Yours will likely differ.

Apologies for the wall of text, this went longer than I expected.

1. The motivating example isn't compelling

Of all of the dozens of systems I've worked on, and the uncountable other systems (many hundreds) that I've discussed with people over my career, I'm only aware of one system that actually changed the type used for their database identifiers.

For that system, they had used a 32-bit integer as their primary key and were fast closing in on two billion records in a core table, necessitating a rapid pivot.

Changing the underlying data type was the least of their problems, and a mechanical approach to doing so would only have created problems as every piece of code needed to be carefully reviewd, modified, and tested.

In fact, given that they can't afford any downtime at all, I strongly suspect they would have introduced the second identifier alongside the existing one, with both coexisting for a time as different components were completed and released. (This is conjecture on my part, however.)

2. There are already good patterns for solving this problem that don't require language support

While it's commonly done, there are serious issues with using int or long as a unique identifier.

Those types have a lot of functionality that's irellevant to the use - it doesn't make sense to calcuate CustomerId * 3 or ProductId + 5 or SeriesId % 176 or CustomerId * ProductId.

Same applies to the use of string - why would CourseId.Length ever be useful?

Using primitive types for unique identifiers is easy, convenient, commonplace, pervasive, and ultimately error prone.

Defining a custom struct type for an identifier is a simple, straightforward exercise that not only avoids the problems caused by use of primitive types but makes this proposed language feature irellevant.

For example, here's a TimeSeriesId from my blog:

public struct TimeSeriesId : IEquatable<TimeSeriesId>
{
    private readonly string _id;
    public TimeSeriesId(string id)
        => _id = IsValidId(id)
            ? id 
            : throw new ArgumentNullException(nameof(id));
    public static bool IsValidId(string id)
        => !string.IsNullOrWhiteSpace(id);
    public bool Equals(TimeSeriesId id)
        => string.Equals(_id, id._id, StringComparison.OrdinalIgnoreCase);
    public override bool Equals(object obj)
        => obj is TimeSeriesId id && Equals(id);
    public override int GetHashCode()
        => StringComparer.OrdinalIgnoreCase.GetHashCode(_id);
}

3. Poor return on investment for the Language Team

The C# Language team has limited time and resources (Microsoft might be a very large company, but it also has a very large portfolio of products); the actual number of people working on C# is surprisingly small.

Given this, they need to prioritize their efforts - and we can see from recent history the kinds of changes that make it across the finishing line.

Expression bodied members (methods, getters and setters) only provide a minor benefit each time they're used, but they're used so often that the overall total becomes quite significant. My guess is that their implementation was relatively simple.

The async and await contextual keywords provide enormous value whe used, because they make asyncronous programming accessible to us mere mortals. While the feature was difficult (and therefore expensive) to implement, the benefit when used is substantial, especially as concurrency becomes a mainstay of high performance computing.

Recently introduced, the half floating point type is very targetted; most people will never need/want it - but for those who do, it's value is high.

I believe that a usetype keyword would be challenging (and therefore expensive) to implement in the compiler (mostly due to edge cases such as chained use, generics, reference assmblies, and binary compatibility), but the benefit to the wider C# would be limited.

Given that there are already good ways to solve this problem that don't require new language support, I don't believe this would be a good use of the teams time.

[deadmann]

Thanks for the wall of text and the time and effort you put in it, as you explained :)

I saw some people gave this feature thumbs down

Well, since you asked nicely. 😁
Warning: Strong opinions ahead. This is my experience, my opinions. Yours will likely differ.

Apologies for the wall of text, this went longer than I expected.

1. The motivating example isn't compelling

Of all of the dozens of systems I've worked on, and the uncountable other systems (many hundreds) that I've discussed with people over my career, I'm only aware of one system that actually changed the type used for their database identifiers.

For that system, they had used a 32-bit integer as their primary key and were fast closing in on two billion records in a core table, necessitating a rapid pivot.

Changing the underlying data type was the least of their problems, and a mechanical approach to doing so would only have created problems as every piece of code needed to be carefully reviewd, modified, and tested.

In fact, given that they can't afford any downtime at all, I strongly suspect they would have introduced the second identifier alongside the existing one, with both coexisting for a time as different components were completed and released. (This is conjecture on my part, however.)

I accept the fact that you explained, unfortunately the product manager changed many entity type just a 2 week after initializing repository and services, and then again after a month of writing application I came across the bug, and fix it in whole system, that was a big alert for me. that's why my mind had to come up with something to address this issue.

• The ID type changed
• The the compiler didn't broke
• The bug become hidden until I start working on that section. hopefully it wasn't on production

2. There are already good patterns for solving this problem that don't require language support

While it's commonly done, there are serious issues with using int or long as a unique identifier.

Those types have a lot of functionality that's irellevant to the use - it doesn't make sense to calcuate CustomerId * 3 or ProductId + 5 or SeriesId % 176 or CustomerId * ProductId.

Same applies to the use of string - why would CourseId.Length ever be useful?

Using primitive types for unique identifiers is easy, convenient, commonplace, pervasive, and ultimately error prone.

Defining a custom struct type for an identifier is a simple, straightforward exercise that not only avoids the problems caused by use of primitive types but makes this proposed language feature irellevant.

For example, here's a TimeSeriesId from my blog:

public struct TimeSeriesId : IEquatable<TimeSeriesId>
{
    private readonly string _id;
    public TimeSeriesId(string id)
        => _id = IsValidId(id)
            ? id 
            : throw new ArgumentNullException(nameof(id));
    public static bool IsValidId(string id)
        => !string.IsNullOrWhiteSpace(id);
    public bool Equals(TimeSeriesId id)
        => string.Equals(_id, id._id, StringComparison.OrdinalIgnoreCase);
    public override bool Equals(object obj)
        => obj is TimeSeriesId id && Equals(id);
    public override int GetHashCode()
        => StringComparer.OrdinalIgnoreCase.GetHashCode(_id);
}

You are right in here as well and I learned some from you.
As for me, to change codes..., I'm afraid I have low privilege to gave my opinion around, the project owner, even some time force me to write character by character of code in his opinion, otherwise I rather liked to use GUID or string as you said, but I never cared or hear what you explained.
When I do something good I have to be careful about what I say, as he's the type to answer before here, taking aggressive mood same to many other people, so either my code should be something unique, or well written that he him self ask me why I do that, or I have something in my hand that... it's hard to explain.
But as I explained I found better use for it to, not just doing with ID.

3. Poor return on investment for the Language Team

The C# Language team has limited time and resources (Microsoft might be a very large company, but it also has a very large portfolio of products); the actual number of people working on C# is surprisingly small.

Given this, they need to prioritize their efforts - and we can see from recent history the kinds of changes that make it across the finishing line.

Expression bodied members (methods, getters and setters) only provide a minor benefit each time they're used, but they're used so often that the overall total becomes quite significant. My guess is that their implementation was relatively simple.

The async and await contextual keywords provide enormous value whe used, because they make asyncronous programming accessible to us mere mortals. While the feature was difficult (and therefore expensive) to implement, the benefit when used is substantial, especially as concurrency becomes a mainstay of high performance computing.

Recently introduced, the half floating point type is very targetted; most people will never need/want it - but for those who do, it's value is high.

I believe that a usetype keyword would be challenging (and therefore expensive) to implement in the compiler (mostly due to edge cases such as chained use, generics, reference assmblies, and binary compatibility), but the benefit to the wider C# would be limited.

Given that there are already good ways to solve this problem that don't require new language support, I don't believe this would be a good use of the teams time.

By half floating point type, do you mean variable int and float size buy CPU architecture?
Yeah you are totally right, as I saw their versioning sprit with undone tasks too. Yet I hope and believe, when it comes to reflection, and that is some part that allow to write robust architectural codes and automated scenarios, it can become a great and powerful tools, and doing that in the underlying system, would make these reflection commands even faster, as they are no longer reflection and they have few pointer to get the type, faster and without looping through types.
I hope they also look at it in this way, and maybe in their sprint session they consider looking more deeply in it, if it is beneficial or not that much.

[ZacharyPatten]

I saw some people gave this feature thumbs down,... I wish to discuss why you think this feature is bad. and compare it's cons vs its pros

@deadmann I also currently downvoted. And since you asked, here are some of my initial thoughts:

1. This seems very similar to var in that it hides the type behind another layer of indirection. I absolutely hate having to read code that uses var everywhere compared to the contrary. For example, when you use var you currently lose semantic highlighting based on the type-of-type in all major IDEs. This feature would result in similar issues to var.
2. If this style of feature was ever adopted, people would probably want to use it in other places too, such as in an alias: using MyAlias = useType(Xxx.Yyy); or even just local variables Dictionary<useType(Xxx.Yyy), object> mylocal = new(); or other locations, and I just think this is all backwards. Rather than generic parameters or alias's or whatever being relative to a type of a member, the type of a member should be relative to the alias, generic parameter, etc. Like, if there is potential for Xxx.Yyy's type to change, maybe it should be generic rather than hard coded to a specific type; perhaps something like XRepository<int> : BaseRepository<X, int> rather than XRepository : BaseRepository<X, useType(Xxx.Yyy)>.
3. The result is more verbose than the current code in many cases. It isn't cleaning up the code.
4. It isn't saving time (at least in the example provided). Changing the type on members is relatively rare compared to other types of edits, thus having to adjust the relative generic parameter is also relatively rare.
5. If I change the type of the member, I want relative code to break until I revise it so that I know all the code that my change affects. I don't want it to compile as if nothing happened. If this feature was ever added it means that when I change a type of a member, I could cause bugs in any code that uses the type of that member, and I may have no idea unless I remember to check all the useType's that are possible on that member.
6. There are likely better designs for the example you provided than using generics in this manor. Especially when "shapes" become a feature in C#, a lot of inheritance-based patterns will disappear in favor of shapes.
7. The following would likely be possible if this feature became a reality:

public interface IA<T> { public T a { get; } }
public class A<T> : IA<useType(IA<C>.a)> { }
public class B<T> : IA<useType(IA<useType(IA<useType(IA<useType(IA<useType(IA<C>.a)>.a)>.a)>.a)>.a)> { }

I'm sure I would have more thoughts if I gave it further thought, but this just seems like a bad idea.

[deadmann]

First of all I appreaciate your response, and you are very right in many or all ways by my understanding.

1. This seems very similar to var in that it hides the type behind another layer of indirection. I absolutely hate having to read code that uses var everywhere compared to the contrary. For example, when you use var you currently lose semantic highlighting based on the type-of-type in all major IDEs. This feature would result in similar issues to var.

You are absolutely right in this matter, useType hide variable type, and it just give you a reference, same too:

var y = new object(); // It hide type but still readable
var x = y; // This one hide but you have to lookup for y
class w { public object v {get;set;} }
var z = useType(w.v); // This also need lookup

Hopefully Visual Studio IntelliSense grow well to show those type all around project when we do not specify type or break lines or parentheses.

2. If this style of feature was ever adopted, people would probably want to use it in other places too, such as in an alias: using MyAlias = useType(Xxx.Yyy); or even just local variables Dictionary<useType(Xxx.Yyy), object> mylocal = new(); or other locations, and I just think this is all backwards. Rather than generic parameters or alias's or whatever being relative to a type of a member, the type of a member should be relative to the alias, generic parameter, etc. Like, if there is potential for Xxx.Yyy's type to change, maybe it should be generic rather than hard coded to a specific type; perhaps something like XRepository<int> : BaseRepository<X, int> rather than XRepository : BaseRepository<X, useType(Xxx.Yyy)>.

Well unfortunately we can't decide for how people code, and I can give you promise that people will behave in good manner, and follow our foot steps.
I and my colleague write APIs in way different manner, although we try to choose a common way, but in reality, we, separately, think different, and that affect our codding style, if we start a project we end up writing what we think is right and that's fully different.
As for the repository, the Xxx in my case is actually an entity, and it happened that my colleague changed the Id type and as the request of FindAsync was of type object, it broke in many place without a single warning.

3. The result is more verbose than the current code in many cases. It isn't cleaning up the code.

Well you are right, if it get misused, it introduce readability complexity beyond ones imagination. as a feature such as goto can do. but it can simplify readability if it get use in write place, n loop inside each other and one of them want to repeat the whole process from specific task that user did before, running out of all those iterations, it either requires so many if checking or it can be handled using only one goto command point to a label before the begin of that action. Yet if user want to use goto for almost all other scenarios, we end up to the point that all programmer in the world start to writing article condemning the use of goto, as we see today, yet goto still is there, because still there are programmers that see it's benefits.
As last word in this section, I can only say this, I hope user of useType() won't abuse it's usage.

4. It isn't saving time (at least in the example provided). Changing the type on members is relatively rare compared to other types of edits, thus having to adjust the relative generic parameter is also relatively rare.

You are right in this matter too, you think about many scenarios very well, without facing the issues.
It isn't save time in the given example, it also requires more time for the third party or read the code. it also require more time to write.
The scenario which in it. this feature saves time, is in:
-Automation of refactoring
-Coding for reflections scenarios (it can boost the process, and ease the implementations), again if the user do not misuse the usage (I had issue that I solved in hard way, and when I though about this feature, that issue come to be much more simpler, today I have no memory of the code, so unfortunately I cannot share it)

5. If I change the type of the member, I want relative code to break until I revise it so that I know all the code that my change affects. I don't want it to compile as if nothing happened. If this feature was ever added it means that when I change a type of a member, I could cause bugs in any code that uses the type of that member, and I may have no idea unless I remember to check all the useType's that are possible on that member.

Again depend on your IDE and compiler, you may, and I'm sure, right,
I used to write everything in visual studio or in combination with resharper, and the IntelliSense is so great that you do not require to recompile to see errors, and in the other scenario as I mentioned above my code at compilation didn't broke, no error at all, but was broken in it's core, error start to show up after a while, and I had too review all my entity models and view-models, because I found some folks, include the person "I", didn't notice the FindAsync may not ever breaks, because it accept object.

6. There are likely better designs for the example you provided than using generics in this manor. Especially when "shapes" become a feature in C#, a lot of inheritance-based patterns will disappear in favor of shapes.

I'm afraid I didn't hear about the concept of shapes, that eliminate inheritance. ain't them part of the same concepts?

7. The following would likely be possible if this feature became a reality:

public interface IA<T> { public T a { get; } }
public class A<T> : IA<useType(IA<C>.a)> { }
public class B<T> : IA<useType(IA<useType(IA<useType(IA<useType(IA<useType(IA<C>.a)>.a)>.a)>.a)>.a)> { }

you are totally write, that's the abusive coder that I talk about it all along, it's like I n time write this code:
It can be like this:

public interface IA<T> { public T A { get; } }
    public class C{}
    public class Z:IA<C>
    {
        public C A { get; }
    }

    public class X
    {
        public object GetObject()
        {
            IA<C> iaInstance = new Z();

            var newObj = iaInstance.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            newObj = (newObj as IA<C>)?.A.GetType().GetConstructor(new Type[] { })?.Invoke(new object[] { });
            return (newObj as IA<C>)?.A.GetType();
        }
    }

I can totally abuse coding in anyway with all existing features, but still it is more complex and more confusing, and even less likely to be detected. also it still doesn't provide option to pass type.

I'm sure I would have more thoughts if I gave it further thought, but this just seems like a bad idea.

So do I; even right now thinking about it, time to time, I couldn't think of so many scenarios in such a long time as you did, even though your answer was a rejection, and you didn't need to think about it at all.