Skip to content

Conversation

@CyrusNajmabadi
Copy link
Member

No description provided.

}
else
{
return Uri.Equals(this.ParsedUri, otherUri.ParsedUri);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note Uri.Equals doesn't exist. it calls through to object.Equals

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure Uri.Equals exists and I am pretty sure we need to use it in some cases to handle casing - https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.Uri/src/System/Uri.cs#L1745

}
else
{
return Uri.Equals(this.ParsedUri, otherUri.ParsedUri);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure Uri.Equals exists and I am pretty sure we need to use it in some cases to handle casing - https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.Uri/src/System/Uri.cs#L1745

@CyrusNajmabadi
Copy link
Member Author

I am pretty sure Uri.Equals exists and I am pretty sure we need to use it in some cases to handle casing - dotnet/runtime@main/src/libraries/System.Private.Uri/src/System/Uri.cs#L1745

That's instance Equals. But this is the static Equals(a, b) being called. Taht has a very simple impl which just does some null checking, and then calls into instance .Equals.

So the prior code was correct, as is the new code. It's just that saying Uri.Equals(a, b) is pointless. It's a call to Object.Equals(a, b).

@dibarbet
Copy link
Member

dibarbet commented Jan 9, 2026

That's instance Equals. But this is the static Equals(a, b) being called

ah of course, for some reason I read Uri as a property.

private Optional<Uri> _parsedUri;

public DocumentUri(string uriString)
public DocumentUri(Uri parsedUri) : this(parsedUri.AbsoluteUri)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is always correct. Nothing is constraining the System.Uri to be an absolute uri,, it could be relative and AbsoluteUri will throw

I think that also even round tripping an absolute URI like this could change how it is parsed - for example possibly percent encoding the Uri twice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i def agree. though that was the existing logic:

    public DocumentUri(Uri parsedUri)
    {
        UriString = parsedUri.AbsoluteUri;
        _parsedUriLazy = new(() => parsedUri);
    }

Any thoughts on what we should do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

edit - the first part of my statement was wrong. it looks like its already doing AbsoluteUri below. But I believe the second still applies. I'm not sure there is a guarantee that Uri.AbsoluteUri == new Uri(Uri.AbsoluteUr)).AbsoluteUri

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to keep the DocumentUri(Uri parsedUri) ctor, and assign the Uri to the Optional<Uri> like we did before?

For the absolute part, it must be the callers that guarantee an absolute URI. I would be an ok with an explicit throw if not absolute here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh. very good catch. i actually had that, but accidentally deleted it. it def should remain!

@CyrusNajmabadi CyrusNajmabadi merged commit a3f1221 into dotnet:main Jan 9, 2026
25 of 26 checks passed
@CyrusNajmabadi CyrusNajmabadi deleted the simplifyDocUri branch January 9, 2026 23:52
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Jan 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants