[swift-evolution] [Idea] Large integer literals

[Dmitri Gribenko]

On Sun, Jul 3, 2016 at 9:20 PM, Brent Royal-Gordon via swift-evolution
<swift-evolution at swift.org> wrote:
> 2. Use a tuple/array of `Int`s/`UInts`
>
> Like `String`, this lends itself to becoming variable-width in a later version; unlike `String`, it's relatively compact. But also unlike `String`, it would be hard to get this working in Swift 3: tuples cannot be conformed to protocols like `_BuiltinIntegerLiteralConvertible`, and there's no conditional conformances to make `[Int]`/`[UInt]` conform to it either.

My recommended approach is to follow the example of DictionaryLiteral,
and define a "transport" data type that can accurately capture the
literal contents.  The transport data type should not have any
operations beyond the bare minimum (not even the BinaryInteger
conformance), so that the users are not tempted to use it as a
big-integer type.

The IntegerLiteral type would probably just wrap an
UnsafeBufferPointer to the readonly data segment, where the compiler
would lay out the literal.  (Very much like StaticString.  Maybe it
should be renamed to StringLiteral?)

I would not recommend wrapping a Builtin.Int2048 by value, this leads
to very inefficient code.  When it comes from the standard library,
this code is currently cleaned up by the optimizer because everything
that touches Builtin.Int2048 is marked @_transparent; but ordinary
frameworks can't do that.



A related issue is that the generic entry point that accepts
Builtin.Int2048 is still emitted by the compiler, and it is actually
called from unspecialized generic code when creating literals of
generic types.

func f<T : Integer>() -> T{
  let x: T = 0
  return x
}

It would be great if we introduced another entry point in
IntegerLiteralConvertible that accepted [U]Int64 (and/or [U]Int128),
which the compiler would prefer if the literal is small (and it
usually is).

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/