[Dot Shorthands] Core library updates

[kallentu]

This issue tracks the changes we want to make to the core libraries with the dot shorthands feature.

I believe we'll have a lint that converts typed static accesses to dot shorthand form (Color.blue -> .blue). Do we want to change any part of the core libraries to use dot shorthands?
And any other changes we need to make?

cc. @lrhn

[lrhn]

There is no urgency.
This is a shorthand that only affects readability of implementation code, not the API. Nobody should be able to see, or care, whether we use the shorthand or not.

We can choose to use it everywhere it applies, as a style statement, or we can update code when we touch it anyway.
The latter has been our strategy so far, so let's just keep doing that.

[kallentu]

Sounds good to me.

[lrhn]

We should probably also consider whether there are any constants that should now be declared inside another class, because you'd want to use shorthands for them.
Enums should be fine, so should constructors, so it's other constants or factory methods that might be candidates, and only ones that are inside another type (if they're inside the correct type, it's fine, and if they're top-level it's already shorter to write name than .name).

I quick search of the core platform libraries (async, collection, core, convert, math, and typed_data) found no static constants that were out-of-place and could reasonably be placed in the declaration of their type.

The Float32x4.xyzw constants stood out, but they won't fit on int.
Maybe if we introduced an extension type for them, like

extension type XYZW(int _) implements int {
  static const XYZW xxxx = 0x00;
  // ...
  static const XYZW www = 0xFF;
}

and made the argument to Float32x4.shuffle be XYZW.
It would be breaking, though, if anyone uses int to store a shuffling temporarily, rather than just using a constant directly.

So probably nothing further to do, but platform specific libraries might want to check.

[lrhn]

Same suggestion has been made for Month and Weekday as arguments to DateTime.
Same issue applies: It's breaking to change the parameter type to an extension type Month(int _) implements int, and without that, the dot-shorthand won't work anyway.

Solutions, long-term, would be to have "extension type aliases" which are both subtypes and supertypes of the representation type, so int would be assignable to Month, and we can safely change the parameter type to Month,
or have implicit coercions from int to Month, fx implicit constructors, *or* add a way to override the scope of dot shorthands, like , int month from Month`.

Nothing to do right now.

[mmcdon20]

@lrhn Another potential use case would be the constants in HttpHeaders

sdk/sdk/lib/_http/http.dart

Lines 337 to 409 in 8516bc1

	abstract interface class HttpHeaders {
	static const acceptHeader = "accept";
	static const acceptCharsetHeader = "accept-charset";
	static const acceptEncodingHeader = "accept-encoding";
	static const acceptLanguageHeader = "accept-language";
	static const acceptRangesHeader = "accept-ranges";
	@Since("2.14")
	static const accessControlAllowCredentialsHeader =
	'access-control-allow-credentials';
	@Since("2.14")
	static const accessControlAllowHeadersHeader = 'access-control-allow-headers';
	@Since("2.14")
	static const accessControlAllowMethodsHeader = 'access-control-allow-methods';
	@Since("2.14")
	static const accessControlAllowOriginHeader = 'access-control-allow-origin';
	@Since("2.14")
	static const accessControlExposeHeadersHeader =
	'access-control-expose-headers';
	@Since("2.14")
	static const accessControlMaxAgeHeader = 'access-control-max-age';
	@Since("2.14")
	static const accessControlRequestHeadersHeader =
	'access-control-request-headers';
	@Since("2.14")
	static const accessControlRequestMethodHeader =
	'access-control-request-method';
	static const ageHeader = "age";
	static const allowHeader = "allow";
	static const authorizationHeader = "authorization";
	static const cacheControlHeader = "cache-control";
	static const connectionHeader = "connection";
	static const contentEncodingHeader = "content-encoding";
	static const contentLanguageHeader = "content-language";
	static const contentLengthHeader = "content-length";
	static const contentLocationHeader = "content-location";
	static const contentMD5Header = "content-md5";
	static const contentRangeHeader = "content-range";
	static const contentTypeHeader = "content-type";
	static const dateHeader = "date";
	static const etagHeader = "etag";
	static const expectHeader = "expect";
	static const expiresHeader = "expires";
	static const fromHeader = "from";
	static const hostHeader = "host";
	static const ifMatchHeader = "if-match";
	static const ifModifiedSinceHeader = "if-modified-since";
	static const ifNoneMatchHeader = "if-none-match";
	static const ifRangeHeader = "if-range";
	static const ifUnmodifiedSinceHeader = "if-unmodified-since";
	static const lastModifiedHeader = "last-modified";
	static const locationHeader = "location";
	static const maxForwardsHeader = "max-forwards";
	static const pragmaHeader = "pragma";
	static const proxyAuthenticateHeader = "proxy-authenticate";
	static const proxyAuthorizationHeader = "proxy-authorization";
	static const rangeHeader = "range";
	static const refererHeader = "referer";
	static const retryAfterHeader = "retry-after";
	static const serverHeader = "server";
	static const teHeader = "te";
	static const trailerHeader = "trailer";
	static const transferEncodingHeader = "transfer-encoding";
	static const upgradeHeader = "upgrade";
	static const userAgentHeader = "user-agent";
	static const varyHeader = "vary";
	static const viaHeader = "via";
	static const warningHeader = "warning";
	static const wwwAuthenticateHeader = "www-authenticate";
	static const contentDisposition = "content-disposition";
	// Cookie headers from RFC 6265.
	static const cookieHeader = "cookie";
	static const setCookieHeader = "set-cookie";

[lrhn]

Agree, and same issue applies. If we change the parameter type to a hypothetical extension type const HttpHeaders(String _) on String {...} which contains the values, then any code that stores an argument as String will break.
If we don't change the parameter type, dot-shorthands won't apply.

It's a no-go until we get something like implicit coercion (from String to HttpHeaders) or extension type-alias (so HttpHeaders<:> String, not just HttpHeaders<: String).