April 21
On Friday, 21 April 2017 at 12:32:01 UTC, Nick Sabalausky (Abscissa) wrote:
>
> "Completely unnecessary" features like that are exactly what make D worthwhile in the first place. Otherwise may as well stick to C++ or Java.

Multiple ways of doing the same thing are not valuable or progressive.

Go and Rust are both smashing D in popularity and user share, maybe we could learn why that's the case.
April 21
Gary Willoughby wrote:

> Go and Rust are both smashing D in popularity and user share, maybe we could learn why that's the case.

'cause go backed by google, and rust backed by mozilla.
April 21
On Friday, 21 April 2017 at 12:45:39 UTC, Gary Willoughby wrote:
> Multiple ways of doing the same thing are not valuable or progressive.
>
> Go and Rust are both smashing D in popularity and user share, maybe we could learn why that's the case.

Corporate backing and word-of-mouth?

I recall reading a KDE blog article about the problems of internationalizaton where you have large tables of pattern strings (think WelcomeMessage[EN]="Welcome $user to $hostname") where the tokens were very much in different ordering depending on language, or how some may even be considered implicit and ommitted outright. (Japanese springs to mind.)

It was way back now so I don't even know where to begin to start looking, but it highlighted how the ordering did not translate well into printf patterns. Citation needed but it's a use-case this would address.
April 21
On Thursday, 20 April 2017 at 19:02:20 UTC, Kagamin wrote:
> Also how various kinds of strings would work?
> r$"{can}\i\has{slashes}"
> $`same {here}`

r"" and `` are WysiwygStrings. Interpolation is not WYSIWYG.

$"" would need to support escaping of the interpolation start character, so may as well escape with backslash like "" strings.

> $q{{balanced}braces}

q{} strings have to lex correctly, so are intended for code - brace interpolation would play badly with braces in code. It might be useful with mixins if using a different interpolation syntax, e.g. $identifier or ${var+1} syntax within the string:

void fun(string op)(T a, T b){
    mixin(text($q{$a $op= $b;}));
}

(I used `text` for Dmitry's AliasSeq expansion - use `format` for Walter's).
April 21
On Thursday, 20 April 2017 at 21:34:44 UTC, Steven Schveighoffer wrote:
> Dmitry's solution is superior I think:
>
> $"{a} times 3 is {a * 3}"
>
> ->
>
> AliasSeq!(a, " times 3 is ", a * 3)

+1, this is more flexible.

> Would work fine with writeln.

Yep, and std.conv.text. We might want a function that takes the quoted AliasSeq expansion and writes it to an output range.

> Would work fine with format.

No, std.format.format needs a format string as first argument, supplying extra arguments will not work.

I like how this expansion *always* parses the string at compile-time. The expansion could be passed whole as template arguments if desired - I think this would allow text!(seq) which, if passed only literal strings and runtime scalar types, can return a fixed size static array, even though the scalar values are read and formatted at runtime.
April 21
On Thursday, 20 April 2017 at 20:43:35 UTC, H. S. Teoh wrote:
> If you're doing internationalization, though, neither option is a good one (I gave an example using dates in another post): printf-style formats have ordering issues (is it year first, then month, then day? Or month first then day then year? Which argument is which?), and interpolated strings have the problem of exposing variable names to the translators (who are probably non-coders), potentially opening up the possibility of arbitrary code execution via l10n strings.

This is machine checkable though, the translation code could at least check that the interpolated strings in the translations match the source string's interpolations (possibly in a different order).

An issue remaining is: if successive interpolated values depend on the order they are evaluated in, translations can still cause bugs (when they change the order).
April 21
On Friday, 21 April 2017 at 12:45:39 UTC, Gary Willoughby wrote:
>
> Go and Rust are both smashing D in popularity and user share, maybe we could learn why that's the case.

Can't rely on RAII, can't rely on GC.
This is the single biggest problem to me.

GC performs slowly, and RAII is inconsistent(no default ctors, can be nested in GC objects, etc..)


April 21
On 04/21/2017 08:45 AM, Gary Willoughby wrote:
> On Friday, 21 April 2017 at 12:32:01 UTC, Nick Sabalausky (Abscissa) wrote:
>>
>> "Completely unnecessary" features like that are exactly what make D
>> worthwhile in the first place. Otherwise may as well stick to C++ or
>> Java.
>
> Multiple ways of doing the same thing are not valuable or progressive.
>
> Go and Rust are both smashing D in popularity and user share, maybe we
> could learn why that's the case.

As other have mentioned, there are plenty of far more more likely reasons for go/rust's popularity over D.

As for not having multiple ways of doing things, that's what single-paradigm languages like Haskell or early versions of Java are for. D is deliberately multi-paradigm, which automatically throws the whole "python zen" philosophy right out the window: D is about letting the user choose the right tool for the job, not dictating that every shape of peg must be jammed into the square hole.

April 21
On Thursday, 20 April 2017 at 18:28:30 UTC, Atila Neves wrote:
> On Monday, 17 April 2017 at 19:38:33 UTC, Kapps wrote:
>> On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
>>> [...]
>>
>> C# got this feature recently. I didn't expect it to be a significant difference, but I do find it a substantial improvement. Not only does it clearly show what goes where, but it's so much cleaner and more convenient.
>
> I don't understand how
>
> writeln($"{a} times 3 is {a * 3}");
>
> is even marginally better than
>
> writeln(a, " times 3 is ", a * 3);  // look ma, works right now!
>
> It's not even fewer characters.
>
> Atila

I find the first one to be cleaner honestly. It shows exactly where values are coming from, doesn't have a bunch of commas that can be annoying to match up, and doesn't start and stop a string multiple times. And for the second one, that's only because writeln specifically includes overloads to take in multiple objects and merge them together. This isn't something functions should have to always do (except in the cases where taking in multiple arguments is actually more efficient, like presumably with writeln since it doesn't need to actually merge the string).

It's not like it's a huge missing feature. Having something like the below isn't too bad:
foo(format("Value of ", a, " * 3 is ", a * 3, "."));
But it's just not as nice as:
foo($"Value of {a} * 3 is {a * 3}.");
August 24
All modern languages like Dart and C# have string interpolation. Sharp example:

Console.WriteLine($"Hello {args[0]}!");

Who can summary is there any objective reasons why it's not realized in D?
1 2 3 4 5 6 7 8 9 10