[swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Jacob Bandes-Storch]

Hi Dave,
I just filed https://bugs.swift.org/browse/SR-2303.

Brainstorming: is it important that the init(stringInterpolation:) and
init(stringInterpolationSegment:) requirements are on the same type?
Perhaps it would work to separate these two requirements, allowing the
segments to construct intermediate types, and only requiring the type
adopting ExpressibleByStringInterpolation to implement
init(stringInterpolation:).

This would be nice because it would be much easier for types which aren't
enums to conform to ExpressibleByStringInterpolation. In my auto layout
example (https://gist.github.com/jtbandes/9c1c25ee4996d2554375), the
ConstraintCollection type is only an enum because it has to provide all the
initializers, but it's strange that the cases are accessible publicly;
ideally it would just be a struct with no public initializers besides
init(stringInterpolation:). For example:

    enum InterpolationSegment<T: InterpolationSegmentProtocol> {
        case stringLiteral(String)
        case interpolatedValue(T)
    }

    protocol InterpolationSegmentProtocol {
        // Might want to implement init(stringInterpolationSegment:) for
multiple types,
        // so we can't require a single associated value (same with
ExpressibleByStringLiteral today)
    //    associatedtype Value
    //    init(stringInterpolationSegment value: Value)
    }

    protocol MyExpressibleByStringInterpolation {
        associatedtype Segment: InterpolationSegmentProtocol
        init(stringInterpolation: InterpolationSegment<Segment>...)
    }

    // Foo is constructed from a string interpolation containing only
    // String pieces and Foo.Segment pieces.
    struct Foo: MyExpressibleByStringInterpolation {
        struct Segment: InterpolationSegmentProtocol {
            init(stringInterpolationSegment value: Int) {}
            init(stringInterpolationSegment value: Double) {}
        }
        init(stringInterpolation: InterpolationSegment<Segment>...) {
            // ...
        }
    }

    let x: Foo = "abc\(3)def"
    // translated to
    Foo(stringInterpolation:
        .stringLiteral("abc"),
        .interpolatedValue(.init(stringInterpolationSegment: 3)),
        .stringLiteral("def"))


Jacob

On Mon, Aug 8, 2016 at 5:57 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Sat Jul 30 2016, Jacob Bandes-Storch <swift-evolution at swift.org> wrote:
>
> > In the past, there has been some interest in refining the behavior of
> > ExpressibleByStringInterpolation (née StringInterpolationConvertible),
> for
> > example:
> >
> > - Ability to *restrict the types that can be used* as interpolation
> segments
> > - Ability to *distinguish the string-literal segments* from interpolation
> > segments whose type is String
>
> Hi Jacob,
>
> I see you've already filed a Jira for the second bullet.  Can you file
> one for the first one?  We're going to redesign
> ExpressibleByStringInterpolation for Swift 4 and solve these problems.
>
> Thanks,
>
> > Some prior discussions:
> > - "StringInterpolationConvertible and StringLiteralConvertible
> inheritance"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160516/017654.html
> > - Sub-discussion in "Allow multiple conformances to the same protocol"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160606/020746.html
> > - "StringInterpolationConvertible: can't distinguish between literal
> > components and String arguments"  https://bugs.swift.org/browse/SR-1260
> > / rdar://problem/19800456&18681780
> > - "Proposal: Deprecate optionals in string interpolation"
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160516/018000.html
> >
> > About Swift 4, Chris wrote:
> >
> >>  - *String re-evaluation:* String is one of the most important
> >> fundamental types in the language.  The standard library leads have
> >> numerous ideas of how to improve the programming model for it, without
> >> jeopardizing the goals of providing a unicode-correct-by-default model.
> >> Our goal is to be better at string processing than Perl!
> >
> > I'd be interested in any more detail the team can provide on this. I'd
> like
> > to talk about string interpolation improvements, but it wouldn't be wise
> to
> > do so without keeping an eye towards possible regex/pattern-binding
> syntax,
> > and the String refinements that the stdlib team has in mind, if there's a
> > chance they would affect interpolation.
> >
> > Discuss!
> >
> > -Jacob
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160808/44830f43/attachment.html>