dotnet / dotnet/csharpstandard

§8.8: Is IntPtr as an unmanaged type an extension?

Open
#890 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
C#
Stars
815
Forks
99
Avg merge
1d 14h
Merged PRs (30d)
16

Description

**Describe the bug**

C# 7.x draft §8.8 (Unmanaged types) is not clear on whether System.IntPtr and System.UIntPtr can be unmanaged types.

It first says:

> An *unmanaged_type* is any type that isn’t a *reference_type*, a *type_parameter*, or a constructed type, and contains no fields whose type is not an *unmanaged_type*.

Based on that definition, System.IntPtr and System.UIntPtr could be unmanaged types, as the specification does not require them to contain any "fields whose type is not an *unmanaged_type*."

The text continues:

> In other words, an *unmanaged_type* is one of the following:
>
> - `sbyte`, `byte`, `short`, `ushort`, `int`, `uint`, `long`, `ulong`, `char`, `float`, `double`, `decimal`, or `bool`.
> - Any *enum_type*.
> - Any user-defined *struct_type* that is not a constructed type and contains fields of *unmanaged_type*s only.

System.IntPtr and System.UIntPtr do not match this second definition, as they are struct types but not user-defined; they are required by §C.2 (Standard Library Types defined in ISO/IEC 23271).

**Example**

If an implementation allows the following, is that an extension (that would have to be documented)?

```csharp
unsafe class C {
System.IntPtr* p;
}
```

**Expected behavior**

Allow System.IntPtr and System.UIntPtr to be unmanaged types even though they are not user-defined.

**Additional context**

C# 11 will require IntPtr and UIntPtr to be unmanaged types.

On .NET Framework, pre-Roslyn "Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.9149" `/langversion:ISO-1` treats IntPtr as an unmanaged type.

Found while perusing .

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.