<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:media="http://search.yahoo.com/mrss/"

	>
<channel>
	<title>
	Comments on: What&#8217;s Coming in Swift 6.4	</title>
	<atom:link href="https://wadetregaskis.com/whats-coming-in-swift-6-4/feed/" rel="self" type="application/rss+xml" />
	<link>https://wadetregaskis.com/whats-coming-in-swift-6-4/</link>
	<description></description>
	<lastBuildDate>Wed, 24 Jun 2026 23:58:05 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: Anonymous		</title>
		<link>https://wadetregaskis.com/whats-coming-in-swift-6-4/#comment-7075</link>

		<dc:creator><![CDATA[Anonymous]]></dc:creator>
		<pubDate>Wed, 24 Jun 2026 23:58:05 +0000</pubDate>
		<guid isPermaLink="false">https://wadetregaskis.com/?p=9117#comment-7075</guid>

					<description><![CDATA[The addition of `isTriviallyIdentical` is very helpful for a small set of use cases, but it is not an &quot;optimized&quot; version of `==`, and does not replace it. The identity test is merely exposing a common fast path condition that `==` usually already incorporates: if the two values have precisely the same representation, then they are guaranteed to be equal. 

Having this exposed is useful, because it allows one to very quickly disprove whether (say) a copy of an array has diverged from the original, to avoid having to laboriously compare before/after states. But an identity check is no substitute for the real `==`: two values can be (and often are) equal even if they aren&#039;t identical.

The lack of a protocol and the lack of `isTriviallyIdentical` methods on basic scalar types like `Int` or `Bool` is simply a consequence of the niche nature of this operation, and the lack of agreement on what the protocol should look like. The Standard Library ships the operation on types where defining it outside the library would require unsafe operations and/or encapsulation violations (such as looking at the raw bytes within the representation of an instance). Having the operations allows developers to design protocols on their own, if and when they need them.]]></description>
			<content:encoded><![CDATA[<p>The addition of `isTriviallyIdentical` is very helpful for a small set of use cases, but it is not an &#8220;optimized&#8221; version of `==`, and does not replace it. The identity test is merely exposing a common fast path condition that `==` usually already incorporates: if the two values have precisely the same representation, then they are guaranteed to be equal. </p>
<p>Having this exposed is useful, because it allows one to very quickly disprove whether (say) a copy of an array has diverged from the original, to avoid having to laboriously compare before/after states. But an identity check is no substitute for the real `==`: two values can be (and often are) equal even if they aren&#8217;t identical.</p>
<p>The lack of a protocol and the lack of `isTriviallyIdentical` methods on basic scalar types like `Int` or `Bool` is simply a consequence of the niche nature of this operation, and the lack of agreement on what the protocol should look like. The Standard Library ships the operation on types where defining it outside the library would require unsafe operations and/or encapsulation violations (such as looking at the raw bytes within the representation of an instance). Having the operations allows developers to design protocols on their own, if and when they need them.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
