<p>One of the stranger features of Swift is <em>color literals</em> -- invocations of the <code>#colorLiteral</code> macro that look like colored squares in Xcode.</p>
<p><a href="https://i.sstatic.net/k1EII.png" rel="noreferrer"><img src="https://i.sstatic.net/k1EII.png" alt="let red: UIColor = #colorLiteral(red: 0.68627450980392157, green: 0.20784313725490197, blue: 0.12941176470588234, alpha: 1.0)" /></a></p>
<p>In this image, the macro invocation is <code>#colorLiteral(red: 0.68627450980392157, green: 0.20784313725490197, blue: 0.12941176470588234, alpha: 1.0)</code> in source, but Xcode renders it as a red square, and you can click on it to open a color picker. Color literals can be used for the types <code>UIColor</code>, <code>NSColor</code>, and <code>CGColor</code> (but not <code>CIColor</code> or <code>SwiftUI.Color</code>).</p>
<p>As useful of a feature this can be, it has its drawbacks, and I'm not entirely sure what would lead someone to come up with it. What considerations should be made when contemplating features like this?</p>

<language-design><literals><swift>
Why color literals?
CC BY-SA 4.0
2023-06-02T12:13:31.503Z
Do you mean why have color literals in a language, or why render them like this in an IDE?
kaya3
CC BY-SA 4.0
2023-06-02T12:18:00.920Z
"*it has its drawbacks*" — listing a few would improve the question. Also listing a few advantages would help too..
Ray Butterworth
CC BY-SA 4.0
2023-06-02T12:47:36.993Z
@kaya3 I meant as a feature in the language itself. As Glorfindel points out in his answer, showing the color in the IDE can be done without language-level support.
Bbrk24
CC BY-SA 4.0
2023-06-02T12:59:48.217Z
So I think the question is, why have a literal syntax for colors, rather than just making them a data type in the standard library that can be constructed the same way any other data structure is? Although in Swift's case, it's a macro, which is not exactly the same thing as a syntax for literals.
kaya3
CC BY-SA 4.0
2023-06-02T13:04:18.157Z
Macros are still experimental in Swift, and `#colorLiteral` was implemented long before it was possible for Swift users to write their own macros.
Bbrk24
CC BY-SA 4.0
2023-06-04T22:50:15.720Z
I’m voting to close this question because this is about IDE features more than the programming languages themselves.
CPlus
CC BY-SA 4.0
2023-06-29T01:34:06.353Z
Just as a note on this, colour literals are a special (and simple) case of intentional programming, where IDEs are aware of domain-specific notation. https://en.wikipedia.org/wiki/Intentional_programming
Pseudonym
<ul>
<li><p>You <strong>immediately see the effect a change would have</strong>; while I can guess the approximate color given a set of RGB values, it's better to have a visual confirmation. The color picker allows to save a color palette or the necessity of an external tool.</p>
</li>
<li><p>It uses up <strong>less space</strong> (your #colorLiteral is over 100 characters, though most of that is because of unnecessary precision).</p>
</li>
</ul>
<p>I see more IDEs that do a combination, showing both the color and the literal:</p>
<p><a href="https://i.sstatic.net/AHvPf.png" rel="noreferrer"><img src="https://i.sstatic.net/AHvPf.png" alt="enter image description here" /></a><br />
(Visual Studio for Mac)</p>
<p><a href="https://i.sstatic.net/0Wp9Z.png" rel="noreferrer"><img src="https://i.sstatic.net/0Wp9Z.png" alt="enter image description here" /></a><br />
(Mendix Studio Pro)</p>

CC BY-SA 4.0
2023-06-02T12:26:42.887Z
2023-06-02T12:26:42.887Z
Glorfindel
CC BY-SA 4.0
2023-06-02T12:58:19.653Z
Jetbrains products show the color in the left margin
mousetail 'he-him'
<p>Colour literals are unusual, but not rare, in recent languages. The obvious case of them is languages like HTML and CSS, where colour is a core presentational facet and there are <em>several</em> styles of literal available. In these contexts such literals have a long history. There are several reasons for adopting them into modern languages in the way you've observed.</p>
<h2>Specialist editing affordances</h2>
<p>Advanced literals of the sort in your screenshot have been very common in recent quasi-visual languages, and languages intended to be tightly integrated with advanced editors. They are used <strong>to provide specialised editing affordances</strong>. A significant example of this is <a href="https://hazel.org/papers/livelits-paper.pdf" rel="noreferrer">Hazel's &quot;live literals&quot;</a> (Omar et al. PLDI 2021), where colours are one of multiple literal types offered special affordances by the editor. These editors are specifically for <em>literals</em>, because those are constant values in the program, while a Java-style <code>new Color(1.0, 0.5, 0.3)</code> expression could be changed to use a dynamic variable instead.</p>
<p>For types that it is valuable to have specific editing affordances for, a specific literal form is useful precisely to enable editors like the one in XCode. Colours are a case where the improvement from showing a multidimensional picker is clearly superior to changing the colour by editing numbers.</p>
<hr />
<h2>Colour is processed <em>preattentively</em></h2>
<p>When solely displaying (and not editing) the program source, colour literals rendered as a small swatch in this way have specific benefit that <strong>colour is processed <a href="https://www.interaction-design.org/literature/article/preattentive-visual-properties-and-how-to-use-them-in-information-visualization" rel="noreferrer">preattentively</a></strong>: the reader does not need to think at all to be aware of the value, as they would for even &quot;obvious&quot; colour triples.</p>
<p>The colour literal fits in the same niche as numeric or string literals that concisely construct values for the program, but can actually be understood <em>more</em> effectively than even a single numeric literal. This is a well-known information design fact, but can also lead to confounding situations when it distracts the viewer.</p>
<hr />
<h2>Visual elements are core to the language purpose</h2>
<p>Not all kinds of program are going to feature colours significantly, and so for many languages it's likely not worth the overhead. Others are not expected to be used predominantly with any specific tool, which negates the contribution of editing affordances. These are reasons <em>not</em> to include these literals; some languages are in the opposite bucket, where colour literals may be very constructive.</p>
<p>Swift in particular is intended for <strong>user-facing applications and games where colours can be an important semantic component</strong> of the program and not merely a later design or style attribute. In this way, it is likely more useful for Swift to provide a colour literal than it would be for Rust, a language of similar vintage with different goals.</p>
<h2>A cooperating editing environment</h2>
<p>It's also expected that Swift code is <strong>written almost entirely using XCode and Swift Playgrounds, all from the same vendor</strong>, so it can be expected that providing extra support for them is going to reach most users of the language. This is another point in favour for Swift, and for integrated quasi-visual languages; I've built these in myself several times when creating a cohesive integrated programming system. It's a point <em>against</em> for languages expecting to be used in conventional text editors that display only a grid of characters, which is still the case for most general-purpose languages.</p>

CC BY-SA 4.0
2023-06-03T09:24:22.107Z
2023-06-03T09:24:22.107Z
Michael Homer
# Why color literals?
Posted by: username_0 on 2023-06-02
One of the stranger features of Swift is *color literals* -- invocations of the `#colorLiteral` macro that look like colored squares in Xcode.

[![let red: UIColor = #colorLiteral(red: 0.68627450980392157, green: 0.20784313725490197, blue: 0.12941176470588234, alpha: 1.0)](https://i.sstatic.net/k1EII.png)](https://i.sstatic.net/k1EII.png)

In this image, the macro invocation is `#colorLiteral(red: 0.68627450980392157, green: 0.20784313725490197, blue: 0.12941176470588234, alpha: 1.0)` in source, but Xcode renders it as a red square, and you can click on it to open a color picker. Color literals can be used for the types `UIColor`, `NSColor`, and `CGColor` (but not `CIColor` or `SwiftUI.Color`).

As useful of a feature this can be, it has its drawbacks, and I'm not entirely sure what would lead someone to come up with it. What considerations should be made when contemplating features like this?
**Tags:** language-design literals swift
> **Comments:**
> **username_1**: Do you mean why have color literals in a language, or why render them like this in an IDE?  
> **username_2**: "*it has its drawbacks*" — listing a few would improve the question. Also listing a few advantages would help too..  
> **username_0**: @kaya3 I meant as a feature in the language itself. As Glorfindel points out in his answer, showing the color in the IDE can be done without language-level support.  
> **username_1**: So I think the question is, why have a literal syntax for colors, rather than just making them a data type in the standard library that can be constructed the same way any other data structure is? Although in Swift's case, it's a macro, which is not exactly the same thing as a syntax for literals.  
> **username_0**: Macros are still experimental in Swift, and `#colorLiteral` was implemented long before it was possible for Swift users to write their own macros.  
> **username_3**: I’m voting to close this question because this is about IDE features more than the programming languages themselves.  
> **username_4**: Just as a note on this, colour literals are a special (and simple) case of intentional programming, where IDEs are aware of domain-specific notation. https://en.wikipedia.org/wiki/Intentional_programming  
---
## 2 answers
### Answer by username_7 on 2023-06-03. Score: 8 | Accepted answer
Colour literals are unusual, but not rare, in recent languages. The obvious case of them is languages like HTML and CSS, where colour is a core presentational facet and there are *several* styles of literal available. In these contexts such literals have a long history. There are several reasons for adopting them into modern languages in the way you've observed.

## Specialist editing affordances

Advanced literals of the sort in your screenshot have been very common in recent quasi-visual languages, and languages intended to be tightly integrated with advanced editors. They are used **to provide specialised editing affordances**. A significant example of this is [Hazel's "live literals"](https://hazel.org/papers/livelits-paper.pdf) (Omar et al. PLDI 2021), where colours are one of multiple literal types offered special affordances by the editor. These editors are specifically for *literals*, because those are constant values in the program, while a Java-style `new Color(1.0, 0.5, 0.3)` expression could be changed to use a dynamic variable instead.

For types that it is valuable to have specific editing affordances for, a specific literal form is useful precisely to enable editors like the one in XCode. Colours are a case where the improvement from showing a multidimensional picker is clearly superior to changing the colour by editing numbers.

---

## Colour is processed *preattentively*

When solely displaying (and not editing) the program source, colour literals rendered as a small swatch in this way have specific benefit that **colour is processed [preattentively](https://www.interaction-design.org/literature/article/preattentive-visual-properties-and-how-to-use-them-in-information-visualization)**: the reader does not need to think at all to be aware of the value, as they would for even "obvious" colour triples.

The colour literal fits in the same niche as numeric or string literals that concisely construct values for the program, but can actually be understood *more* effectively than even a single numeric literal. This is a well-known information design fact, but can also lead to confounding situations when it distracts the viewer.

---

## Visual elements are core to the language purpose

Not all kinds of program are going to feature colours significantly, and so for many languages it's likely not worth the overhead. Others are not expected to be used predominantly with any specific tool, which negates the contribution of editing affordances. These are reasons *not* to include these literals; some languages are in the opposite bucket, where colour literals may be very constructive.

Swift in particular is intended for **user-facing applications and games where colours can be an important semantic component** of the program and not merely a later design or style attribute. In this way, it is likely more useful for Swift to provide a colour literal than it would be for Rust, a language of similar vintage with different goals.

## A cooperating editing environment

It's also expected that Swift code is **written almost entirely using XCode and Swift Playgrounds, all from the same vendor**, so it can be expected that providing extra support for them is going to reach most users of the language. This is another point in favour for Swift, and for integrated quasi-visual languages; I've built these in myself several times when creating a cohesive integrated programming system. It's a point *against* for languages expecting to be used in conventional text editors that display only a grid of characters, which is still the case for most general-purpose languages.
---
### Answer by username_5 on 2023-06-02. Score: 6
* You **immediately see the effect a change would have**; while I can guess the approximate color given a set of RGB values, it's better to have a visual confirmation. The color picker allows to save a color palette or the necessity of an external tool.
* It uses up **less space** (your #colorLiteral is over 100 characters, though most of that is because of unnecessary precision).

I see more IDEs that do a combination, showing both the color and the literal:

[![enter image description here](https://i.sstatic.net/AHvPf.png)](https://i.sstatic.net/AHvPf.png)  
(Visual Studio for Mac)

[![enter image description here](https://i.sstatic.net/0Wp9Z.png)](https://i.sstatic.net/0Wp9Z.png)  
(Mendix Studio Pro)
> **Comments:**
> **username_6** (2023-06-02): Jetbrains products show the color in the left margin  
---
