On 2/27/2020 3:44 AM, aliak wrote:
Btw: Swift does this for string interpolation and it works very well ->
https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0
I don't know Swift, but this looks like the "generate strings and concatenate
them"
On 2/27/20 5:29 PM, aberba wrote:
There's this ongoing open source game framework by Ikey. I knew him to
be a diehard C guru (from the Solus Project) but is now rocking D, hence
Serpent.
Check is out and support if you can, please.
I don't know how he does it but Ikey can code stuff like
There's this ongoing open source game framework by Ikey. I knew
him to be a diehard C guru (from the Solus Project) but is now
rocking D, hence Serpent.
Check is out and support if you can, please.
I don't know how he does it but Ikey can code stuff like crazy.
On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
> Magic types are not simple and inevitably lead to unexpected corners
> and unresolvable problems. *cough* associative arrays *cough*
[...]
For all the trouble they've given us, built-in AA's is one
On Thu, Feb 27, 2020 at 02:20:14PM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
> On 2/27/20 1:42 PM, H. S. Teoh wrote:
> > Making CTFE AAs usable at runtime is somewhat of a different beast,
> > though. The main problem is that you need to be able to instantiate the
> > binary
On 2/27/2020 6:32 AM, Petar Kirov [ZombineDev] wrote:
I'm not sure where exactly you draw the line, but I would say that C# follows
C's syntax about as much as D does.
C# is very different from C. D is not so different, and close enough that
DasBetterC is very viable. Hindsight being 20/20,
On Thursday, 27 February 2020 at 18:19:03 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
Right, that actually is what my old proposal was (and I fought
for it on the first few pages of the last thread), and this is
very close
On 2/27/20 1:42 PM, H. S. Teoh wrote:
Making CTFE AAs usable at runtime is somewhat of a different beast,
though. The main problem is that you need to be able to instantiate the
binary representation of a runtime AA (the main hash table, and each of
the buckets) at compile-time, and do so in a
On 2/27/2020 1:45 AM, Rainer Schuetze wrote:
The string buffer could also be stack allocated or manually managed with
malloc/free by the string interpolation type.
It's quite a big deal to make that work, and does not address the inherent
inefficiency of it.
printf, for all its faults, is
On Thu, Feb 27, 2020 at 10:11:07AM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
[...]
> Large hidden invisible types are not the problem (look at normal
> dynamic arrays, the large hidden type built into the runtime is a huge
> success I think). The problem is that the compiler
On Thursday, 27 February 2020 at 18:07:19 UTC, Arine wrote:
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't
On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov
[ZombineDev] wrote:
auto s = new_type!(
"hi ", spec(null), ", you are visitor ", spec("%2d")
)(name, count);
I.e. the referenced arguments are passed to the constructor of
new_type.
Right, that actually is what my old
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp
On Thursday, 27 February 2020 at 14:58:20 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov
[ZombineDev] wrote:
2. Have the new type implicitly convert to printf-style args.
I think this is what Adam is proposing. While nice to have, I
don't think it's
On Thursday, 27 February 2020 at 15:11:07 UTC, Steven
Schveighoffer wrote:
[snip]
We're going very off topic here, but I wanted to address this.
Large hidden invisible types are not the problem (look at
normal dynamic arrays, the large hidden type built into the
runtime is a huge success I
On Thursday, 27 February 2020 at 15:12:23 UTC, Adam D. Ruppe
wrote:
error: cannot implicitly convert argument of type interpolated
tuple to type string. Tip: use `.idup` to explicitly convert it
to string.
Oh, that pretty much sorts out my problem there, sorry if I
glanced over it being
On 2/27/20 9:32 AM, Petar Kirov [ZombineDev] wrote:
An example of this is the built-in associative array, which has a
series of
fairly intractable problems as a result. Another example is the built-in
complex type in D, which turned out to be a bad idea - a much better
one is
building it as a
On Thursday, 27 February 2020 at 14:47:55 UTC, SealabJaster wrote:
At that point, it begs the question of why even bother having
string interpolation.
I encourage you to read my document too:
https://github.com/dlang/DIPs/pull/186
It addresses all these concerns. Walter's proposal is dead.
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov
[ZombineDev] wrote:
2. Have the new type implicitly convert to printf-style args. I
think this is what Adam is proposing. While nice to have, I
don't think it's necessary.
You can read my document for more detail
On 28/02/2020 3:47 AM, SealabJaster wrote:
Similarly, as far as I can tell even with the adjustment of making these
strings their own special type, something as simple (for other languages
as):
```
void f(string a, string b)
{ /*...*/ }
int foo = 20;
string bar = "lalafell";
f(i"You are a
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
You can make it behave like all those other languages simply
with:
f(format("hello $a"));
At that point, it begs the question of why even bother having
string interpolation.
I'd like to imagine that most
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
[snip]
You're arguing against a strawman. The other poster's comment was
showing a likely problem with the (rejected) dip 1027, that our
new proposal
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this
behavior. My argument is that this behavior is so ubiquitous
that not following it would be surprising to much
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this
behavior. My argument is that this behavior is so ubiquitous
that not following it would be surprising to much
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp
On Thursday, 27 February 2020 at 09:45:06 UTC, Rainer Schuetze
wrote:
On 27/02/2020 01:20, Walter Bright wrote:
On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote:
In all other languages with string interpolation that I'm
familiar with, `a` is not passed to the `i` parameter.
All rely on a
On 27/02/2020 01:20, Walter Bright wrote:
> On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote:
>> In all other languages with string interpolation that I'm familiar
>> with, `a` is not passed to the `i` parameter.
>
> All rely on a garbage collected string being generated as an
>
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be generated
On Thursday, 27 February 2020 at 09:05:47 UTC, JN wrote:
"Class deallocator have been deprecated in v2.080.0 (see ), and
turned into an error in v2.087.0. They have now been completely
removed from the language, and the parser won't recognize them
anymore."
missing a link after the see
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this behavior. My
argument is that this behavior is so ubiquitous that not following it would be
surprising to much more people, than if D didn't follow C's Usual Arithmetic
On Wednesday, 26 February 2020 at 20:57:53 UTC, H. S. Teoh wrote:
On Wed, Feb 26, 2020 at 08:45:31PM +, Atila Neves via
Digitalmars-d-announce wrote:
On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote:
> On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves
> wrote:
> >
On 2/26/2020 10:38 PM, FeepingCreature wrote:
On Thursday, 27 February 2020 at 03:50:35 UTC, Walter Bright wrote:
On 2/26/2020 4:46 PM, Adam D. Ruppe wrote:
But DIP1027 had a fatal flaw: it made type safety impossible.
I don't see how that is true.
Because it turned a format string into a
On Wednesday, 26 February 2020 at 12:17:43 UTC, Martin Nowak
wrote:
Glad to announce the first beta for the 2.091.0 release, ♥ to
the 55 contributors.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.091.0.html
Due to updating several components in the build pipeline,
On Thursday, 27 February 2020 at 00:20:27 UTC, Walter Bright
wrote:
On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote:
In all other languages with string interpolation that I'm
familiar with, `a` is not passed to the `i` parameter.
All rely on a garbage collected string being generated as
34 matches
Mail list logo
