Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2

[Schrom, Brian T]

I'm not sure if this will help, or if this is correct for D's philosophy, 
but maybe it'll inspire some clarification and I can get more clarity myself.

I see there being multiple abstraction levels, and placing this
library at one might help with expectations.

Compiler : 
    - Abstraction over computer hardware
Core/low-level libraries:  
    - Abstraction of primitive things that might be in some 
      compilers, but can also be implemented as a library, 
      for example AAs are a good fit for here.
    - Abstraction of OS features.

Intermediate libs:  
    - Maybe DB APIs fit here.

User facing libraries:  
    - User APIs and maybe even tailored for a specific domain.

I see the interpolation library being the core/low-level
library/compiler that other libraries would be built on to provide a nice user
interface.  I don't think it's desirable to have a monolithic chunk
of code cover the entire vertical between compiler and user facing
library.

On Wed, Feb 03, 2021 at 12:40:40PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> Check twice before you click! This email originated from outside PNNL.
> 
> 
> On 2/3/21 11:52 AM, Q. Schroll wrote:
> > On Friday, 29 January 2021 at 12:58:32 UTC, Dukc wrote:
> > > On Thursday, 28 January 2021 at 14:58:36 UTC, Steven Schveighoffer at
> > > the feedback theard wrote:
> > > > On 1/28/21 3:35 AM, Dukc wrote:
> > > > > The DIP states that foo(i"a:${a}, ${b}.") is rewritten as
> > > > > `foo(Interp!"a:", a, Interp!", ", b, Interp!".")`. It think it's
> > > > > better to rewrite it as `foo(Interp!"a:", Interp!typeof(a)(a),
> > > > > Interp!", ", Interp!typeof(b)(b), Interp!".")`. That way, `foo` has
> > > > > easier time introspecting which came from the interpolated string.
> > > > 
> > > > First, I don't think it's critical for overloading, and will simply
> > > > add to the template bloat. What are you going to do differently with
> > > > `a` than you would with `Interp!(typeof(a))(a)`?
> > > 
> > > I was mainly thinking that I'd have easier time differentiating
> > > between an `int` in interpolated string and `int` passed before/after
> > > the interpolated string. And I have a type that will implicitly
> > > convert to string if I want to do that - no need to call
> > > `to!string(a)` or `a.Interp!(typeof(a))` first.
> > > 
> > > > The parameters are guaranteed to start and end with an
> > > > InterpolationLiteral, so one can assume that non-literal arguments
> > > > are interspersed inside the literal.
> > > 
> > > It can be done, but it sounds more complex for the introspecting
> > > function. I'm not strict about this though, what the DIP now proposes
> > > be worth it to be able to pass `ref` parameters in interpolated strings.
> > > 
> > > > 
> > > > > The type of interpolated string literal is very special cased. [snip]
> > > > 
> > > > I was fully aware that this would be the most controversial part. I
> > > > feel like it will not be full of corner cases, but I'm not sure. Can
> > > > you specify any?
> > > > 
> > > > Consider a normal string literal can be used as a string,
> > > > immutable(char)*, wstring, or dstring. I find it very similar to this
> > > > feature, and I don't feel like there are a lot of corner cases there.
> > > 
> > > A string literal is a string that is implicitly assignable to the
> > > other alternatives via value range propagation mechanics, or that's
> > > how I understand it at least.
> > > 
> > > The compromise that the interpolated string would be an expanded
> > > tuple, that would be implicitly assignable to string via value range
> > > propagation mechanics, sounds acceptable. But it needs to be clear IMO
> > > what the primary type of an interpolated string is. If it is not an
> > > expanded tuple, what it is then? I mean that this must be guaranteed
> > > to pass IMO:
> > 
> > Sorry, I'm late to the game here. This reminds me of slices vs static
> > arrays.
> > As a reminder, to a newcomer,
> >      auto xs = [ 1, 2, 3 ];
> > looks like it would infer int[3] as the type of xs. It is obviously the
> > most descriptive type for the literal. Why would it infer int[]
> > forgetting its compile-time known length and even do an allocation? That
> > seems so much worse. Even typeof([1,2,3]) is int[] and not int[3]. We
> > know why D does it the way it does and goes int[3] with no allocation
> > only if requested explicitly. You can do that with a template with a
> > flexible length like this:
> >      void takesStaticArray(size_t n)(int[n] staticArray);
> > Here, `n` can usually be inferred from the argument.
> > 
> > Interpolated strings could do the exact same thing:
> > 1. make typeof(i"...") result to `string`.
> > 2. make auto str = i"..." infer string (cf. typeof) and gc-allocate if
> > necessary.
> > 3. give i"..." a secondary type akin to [1,2,3] having int[3] as a
> > secondary type.
> 
> I don't want to do it that way, because then the overload is not easy to
> ask for. I really really don't want the string form to be passed into a
> vararg template.
> 
> I've been having second thoughts about having auto x = i"..."; be a
> string, and typeof(i"...") be a string. See my later response here:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforum.dlang.org%2Fpost%2Frv6jr4%24uor%241%40digitalmars.com&data=04%7C01%7CBrian.Schrom%40pnnl.gov%7Cda10ec4e4c034e0a054208d8c86baca4%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637479712088503672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3GOz3kCaI0uWy46w9WGaktDy5XpqdCnQplBg%2FUiN6DI%3D&reserved=0
> 
> > If an interpolated string is bound to a parameter of that secondary type
> > (`interp` in the DIP) it uses its secondary type (cf. calling
> > takesStaticArray with [1,2,3]). In any other case, e.g. `auto` or
> > otherwise generic template parameters will infer string.
> > 
> > Getting a string is probably what most users expect most of the time.
> > Handling the secondary type must be explicit. It is almost an
> > implementation detail that shouldn't be exposed to the user too easily.
> 
> I'm not sure how this could be possible. You can't say T... and have it
> match the tuple over the string, unless the primary type is the tuple.
> 
> But if you have ideas, surely I'd prefer it to be a string first in most
> cases!
> 
> -Steve