StaticString until StaticBigInt

[oscbyspro]

Lowering the minimum platform requirements (#61) means that StaticBigInt be disabled by default. I'll add an ExpressibleByStringLiteral conformance to NBKDoubleWidth in its place. It will work like init(_:radix:) except it will also support the 3 most common radix prefixes: 0b, 0o and 0x. So, ideally, the change is reduced to adding quotation marks.

[oscbyspro]

I suppose one somewhat surprising thing is that conforming to ExpressibleByStringLiteral causes UInt256("123") to call init(stringLiteral:) as opposed to init?(_ description:) from LosslessStringConvertible, because there's a special case for literals. So UInt256(" 23") crashes instead of returning nil. Dunno, if that's a problem. It probably isn't given that literals are known at compile time.

[ypopovych]

one remark - enable String Literal for SBI too. Right now it will be disabled when the SBI flag is set. They can both be present.

• +SBI: StaticBigInt + String
• -SBI: Int64 + String

[oscbyspro]

You're right that these methods can coexist, but should they when one is clearly better? I suppose I can alleviate some migration pain by conditionally deprecating it. Or, do you have a use case in mind that prefers init(stringLiteral:) undeprecated? I'm thinking something like:

#if swift(>=5.8) && SBI
@available(swift, deprecated: 5.8, message: "Use an integer literal instead.")
#endif
@inlinable public init(stringLiteral source: StringLiteralType) { ... }

[ypopovych]

I think it can be used with some APIs which return strings with prefixes even if we have StaticBigInt. Maybe JSON-based API with big integers in it as hex values. I don't think it should be deprecated.

It's better than radix methods because it checks the prefix of the string.

[oscbyspro]

In that case, wouldn't it be better to have a dedicated method? Perhaps with some format parameters.

#if swift(>=5.8) && SBI
@available(swift, deprecated: 5.8, message: "Use an integer literal instead.")
#endif
@inlinable public init(stringLiteral: StringLiteralType) {
    self.init(fromStringLiteralButBetter: stringLiteral, optionalRadixOrSomething: 10)
}

[ypopovych]

the method is good too. But I think we shouldn't force developers. If someone wants to use string literals - ok. Maybe they want to support older OSes without ifdefs even when they have StaticBigInt

[oscbyspro]

I've been thinking. I'll keep depreciating init(stringLiteral:) from 5.8. I'm open to a radix decoding initializer, but init(stringLiteral:) isn't it. The reason is twofold: A) the signature is non-descriptive. B) if this method should be a member of [U]Int256, then it should also be a member of [U]Int[8-64]. I own neither [U]Int[8-64] nor ExpressibleByStringLiteral, and conforming unowned types to unowned protocols is nasty.

[oscbyspro]

I changed NBKDoubleWidth/StringLiteralType to StaticString from String.

[oscbyspro]

I'll remove the deprecation because there isn't an automatic way of enabling StaticBigInt via availability.