[Proposal] typeof as C++11 decltype

[KalitaAlexey]

Sometimes I want to write something like

internal class Class
{
    private readonly IReadOnlyList<int> values;

    internal Class(typeof(values) values)
    {
        this.values = values;
    }
}

or

internal class Class
{
    private IReadOnlyList<int> values;

    internal void SetValues(typeof(values) values)
    {
        this.values = values;
    }
}

Let's on compilation real type will be substituted

internal class Class
{
    private readonly IReadOnlyList<int> values;

    internal Class(IReadOnlyList<int> values)
    {
        this.values = values;
    }
}

or

internal class Class
{
    private IReadOnlyList<int> values;

    internal void SetValues(IReadOnlyList<int> values)
    {
        this.values = values;
    }
}

[dimaaan]

Use type aliases for that.
using MyList = IReadOnlyList<int>

[KalitaAlexey]

@dimaaan I know about aliases, but more clear way will be to use typeof.

[dimaaan]

@KalitaAlexey More clear way to do what?
Could you provide an example where decltype can give some profit.
What i see is:

1. that code harder to understand (we have to check values type to get ctor paratemer type)
2. It don't makes code shorted
3. changing type of values can lead to unexpected behavior when method is overridden.
4. it does not save us from refactoring, when type is changed

[HaloFour]

I agree. This doesn't appear to solve anything that aliasing doesn't already solve. You example is doubly confusing since you have both a field and a parameter named values so the typeof expression seems circularly referential.

[aluanhaddad]

I would like to add that decltype is a very powerful C++11 feature, but the example scenario does not illustrate this. The main usecase of decltype, as far as I understand, is compile time computation of types which depend on the presence values other types as in the following C++:

template <class T, class U>
auto add(T x, U y) -> decltype(x + y) {
    decltype (x + y) result = x + y;
    return result;
}

In other words, decltype is about having type inference powerful enough to express types that depend on operations between values of other types.

This could be a very useful feature in a language like C#, not that I am proposing it, but the title of this proposal is misleading as it does not illustrate that.

[HaloFour]

@aluanhaddad

That is definitely a more compelling scenario, but I'm still not sure it makes much sense for C# given the lack of compile-time templates.

[aluanhaddad]

@HaloFour I agree, and certainly in C++, decltype is primarily used in conjunction with templates. I just do not want decltype itself to be misrepresented or undersold especially since future additions to C# may make some of its many capabilities more worthwhile. For example in:

template <class T, class U>
auto add(const T& x, const& U y) -> decltype(x + y) {
    decltype (x + y) result = x + y;
    return result;
}

decltype takes constness and references into account

[wizzardmr42]

Can I add that this would be incredibly useful for keeping foreign key ref types in sync in EF and for filter model classes in MVC that reference EF types. See #7715 where I explained in more detail.

Also worth mentioning that I am using type aliases in the meantime and it is a lot more work in a large project with a lot of entities. It also makes a mess of the project level reference lists and it needs to be set up separately in all relevant projects, which is far from ideal. See also http://stackoverflow.com/questions/34457028/declaring-a-property-as-the-same-type-as-a-specific-other-property/34457813#34457813 for more discussion.

[ViIvanov]

@dimaaan, @HaloFour,

For example, using alias directive can not help with generics:

class Class<T>
{
    private readonly IReadOnlyList<T> values;

    internal Class(IReadOnlyList<T> values)
    {
        this.values = values;
    }
}

[HaloFour]

That's what #3993 intends to fix.

[DerpMcDerp]

Here's a less advanced example representing something programmers run into every day in C#:

var foo = whatever();
// the compiler already knows the type of foo, why should I have to specify it?
var asdf = new List<decltype(foo)>();
asdf.Add(foo);

If you wanted to do the above today, you'd have to write something like a wrapper method taking a dummy parameter, e.g.

private static List<T> MakeListOf<T>(T ignored) {
    return new List<T>();
}

var foo = whatever();
var asdf = MakeListOf(foo);
asdf.Add(foo);

The wrapper method usually gets obscured by making it do other stuff, i.e.

private static List<T> MakeListFrom<T>(T value) {
    var ret = new List<T>();
    ret.Add(value);
    return ret;
}

var foo = whatever();
var asdf = MakeListFrom(foo);

Which is how current C# produces the illusion that this feature isn't necessary.

[aluanhaddad]

@DerpMcDerp

var asdf = new [] { foo }.ToList();

[jsphadetula]

//Converting an enum value to its underlying type value
TIntegralValue GetValue(EnumType enumValue)
{
return (typeof(Enum.GetUnderlyingType(EnumType)) enumValue;
}

The sad part is Enum.GetUnderlyingType() is only evaluated at runtime. I think this points to the lack of compile time computation in C#

[gafter]

We are now taking language feature discussion in other repositories:

• https:/dotnet/csharplang for C# specific issues
• https:/dotnet/vblang for VB-specific features
• https:/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https:/dotnet/csharplang/issues, and there is a draft spec at https:/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https:/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https:/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.