On 1/8/2024 8:11 PM, Richard (Rikki) Andrew Cattermole wrote:
> Essentially the lexer is splitting:
> 
> ``i"prefix$(Identifier1 3.2)suffix"``
> 
> Into:
> 
> ``"prefix"``
> 
> Identifier1
> 
> 3.2
> 
> ``"suffix"``

Yes, and see what happens with:

i"pr\\efix$(Identifier1 3.2)suffix"

Are you going to get pr\efix or prefix?

On 09/01/2024 8:17 PM, Walter Bright wrote:
> On 1/8/2024 8:11 PM, Richard (Rikki) Andrew Cattermole wrote:
>> Essentially the lexer is splitting:
>>
>> ``i"prefix$(Identifier1 3.2)suffix"``
>>
>> Into:
>>
>> ``"prefix"``
>>
>> Identifier1
>>
>> 3.2
>>
>> ``"suffix"``
> 
> Yes, and see what happens with:
> 
> i"pr\\efix$(Identifier1 3.2)suffix"
> 
> Are you going to get pr\efix or prefix?

Is equivalent to:

"pr\\efix"

Identifier1

3.2

"suffix"



So you would get ``pr\efix`` as the string value. As the standard rules of double quoted strings would apply in that subset of the i-string.

Both: ``"p\ns"`` and ``i"p\ns"`` is the same thing, ignoring the extra expansion of types/values of i-string's.

On 09/01/2024 8:40 PM, Richard (Rikki) Andrew Cattermole wrote:
> Is equivalent to:
> 
> "pr\efix"

If you use a markdown viewer (like myself) this is probably rendering out to be one backslash.

It is meant to be two, as you need to escape the backslash to get into the value rather than trying to escape the e.

On 09.01.24 04:49, Bruce Carneal wrote:
> Additionally noted earlier: a naked spec (no implementation) tempts us to speculate about the relative difficulty and invasiveness of the eventual, often long delayed, implementation.

But the implementation is easy to change later, the specification is not.

On 1/9/24 00:15, Walter Bright wrote:
> On 1/8/2024 7:50 AM, Nick Treleaven wrote:
>> Wouldn't you just use `std.typecons.Tuple`?
> 
> I never really understood Tuple. It creates a struct that behaves like a tuple.

- It is a proper type.
- It can be used to create ad-hoc groups of values when using generic code.
- It does not expand unless the user asks for it.
- It can be put in data structures.
- It can be returned from functions.
- It has an address.

etc.

On 1/7/24 21:22, Walter Bright wrote:
>>
>> So 1027 is equivalently good in this aspect as long as programmers are conscientious in their definition and use of a typing convention?
> 
> It turns out this is an issue for DIP1036 as well, as db.execi() is the template. I hadn't realized that.
> ...

No, it is not an issue for DIP1036e, because it properly separates out compile-time and runtime data.

> 
>> Unless 1036e is believed to be very difficult to implement correctly, or has nasty cross dependencies that could cause problems later, this would seem to be a bad trade (hypothetical? simplification of implementation in exchange for making things harder for users).
> 
> Apparently DIP1027 is no harder for users than DIP1036.

Yes it is. DIP1027 is impossible for users. It's a low bar.

On 10/01/2024 2:00 AM, BlueBeach wrote:
> To be honest it is hard for me to see the end goal of this strategy. What makes it so hard to discuss this fork and engage on topic? Why not let them at least have their discussion?

It is incredibly easy to go from fully relevant material to original topic, to split out into a different thread for some relevant but not quite relevant and you can't do it after the fact.

Which is what happened here.

On 1/9/24 14:00, BlueBeach wrote:
> On Tuesday, 9 January 2024 at 08:45:03 UTC, whitebyte wrote:
>> It's fascinating that Walter did not relate to this at all, but readily jumped into a lengthy technical discussion of a tangentially related topic.
> 
> Agreed, particularly with the word „fascinating“.
> 
> I think the whole forking situation is kinda sad. This fork will probably go nowhere, that something that had been proven time and time again unfortunately.

Not really. See druntime.

> And I‘m afraid for dlang it will be a net negative too.
> ...

A bit of competition is usually a good thing. It's also not like the two projects have no synergies, they are literally built on the same code base.

> I just reread the whole thread and I think in the first 4 to 5 pages the discussion stayed mostly on topic. But then the discussion first got a little more confrontational when some senior dlang people joined the discussion. Subsequently the entire discussion was basically ended by drowning it in technical detail for the next 5 pages.
> ...

Well, the stubbornly different understanding of technical details of DIP1027 vs DIP1038e is the final straw that spawned the fork.

Also, more senior dlang people tend to use e.g. thunderbird rather than forum.dlang.org, with a threaded view.

> To be honest it is hard for me  to see the end goal of this strategy. What makes it so hard to discuss this fork and engage on topic? Why not let them at least have their discussion?

Walter opened a new thread now.