On 1/7/2024 11:52 AM, brianush1 wrote:
> Not arsd.sqlite, nor any other library, defines their own interpolated strings. Importing a library does not and cannot change the behavior of interpolated strings, that is a misunderstanding. Library functions simple take in the interpolated string using a vararg template and do literally *whatever they want with it,* since they're given all the information about the interpolated string, including the evaluated expressions that were inside the string.

Thanks for the clarification. I had indeed misunderstood it.

So that means db.execi() is the template that adjusts how the call to sql is made. (I had assumed it was part of the sql api, rather than a wrapper.)

This makes it no different than DIP1027 in that regard.

It is not really necessary to have a marker to say if an argument is a literal or a variable. Consider this program:

```
import std.stdio;

void main()
{
    writeln("hello".stringof);
    string foo = "betty";
    writeln(foo.stringof);
}
```

Which, when run, prints:

"hello"
foo

and so a template, by using .stringof, can determine if a tuple element is a string literal or a variable.

On 1/7/2024 11:09 AM, Bruce Carneal wrote:
>> It's true that in order for this to work,
>>
>> ```
>> db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");
>> ```
>> would need to be written as:
>> ```
>> db.execi(xxx!(i"INSERT INTO sample VALUES ($(id), $(name))"));
> 
>> ```
>> where `xxx` is the thoroughly unimaginative name of the
> ...
> 
> 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.


> 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.

On Sun, Jan 07, 2024 at 04:43:17PM +0000, Lance Bachmeier via Digitalmars-d wrote: [...]
> I'd much rather Adam put his time into a fork, rather than the more common approach where he'd post here under various names, make ridiculous claims, and vandalize the discussions. If you're new, you may not have seen the many posts from someone that doesn't like private at the module level.

Are you sure you have your facts straight? AFAIK the pseudonymous trolls who posted about private or this or that complaint were not Adam, they were some other disgruntled former D user who has since left.  AFAIK Adam has never engaged in such tactics and was in close contact with the core D team until the recent spat (which is the culmination of ongoing disagreements on governance that started more recently).


> Whether there are useful insights from this or any other fork will depend on what they do with it. If there's too much incompatibility of code, due to breaking changes, it won't have much effect. There's already Nim, Rust, Go, Zig, etc., to compare with and the forks will in each case be just another language.

Adam has stated (publicly, in the opendlang github discussions) that he does not plan to make major changes to the language that would massively break compatibility.  But of course, if this fork continues independently then over time things will diverge sooner or later.


> > > That D hasn't taken over the world is beside the point; good things aren't always popular, e.g., Scheme, and sometimes bad things are very popular, e.g., Windows, JavaScript, C/C++.
> > 
> > Now this is the point where I have to totally disagree with you. It doesn't suffice for a system to be well designed and great to use "in theory", there must also be tooling, documentation, thousands if not millions of samples, and an active community.
> 
> Not really. Those things come after the userbase gets large. I was using Python in the 1990s and I can assure you that the growth did not come because of good tooling, documentation, or code samples. Similarly, I was using R when you used Emacs or a plain text editor, the documentation was similar to Linux man pages, and you asked questions on a mailing list with Brian Ripley. Only after it took off did they build RStudio. What both languages had was a small, dedicated group of users that were willing and able to build useful things with the language.

As somebody has said, it depends on your definition of "success".  If your definition of success is popularity, then sure, you need a big community, lots of existing code, hype, etc..  By that measure C++ is more successful than D and I should be using C++ instead.  But I came to D not because of popularity, but because of technical merit.  I would rather stay with a small, relatively unknown community where technical excellence plays a deciding role, than in a large community of mediocrity where popularity is the deciding factor.  So my definition of success is rather different from what some have been using when bemoaning the current state of D.


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl

On 1/7/2024 12:08 PM, matheus wrote:
> I think it's this one: 

Thank you. It turns out I had a misunderstanding, so I don't need it.