On Saturday, 29 February 2020 at 14:41:16 UTC, Steven
Schveighoffer wrote:
On 2/28/20 7:57 PM, aliak wrote:
I actually didn't realize it was a video, thought it was just
an article! - But anyway, it was just to point out that swift
lowers to specialized types when it comes to interpolation
On 2/28/20 7:57 PM, aliak wrote:
I actually didn't realize it was a video, thought it was just an
article! - But anyway, it was just to point out that swift lowers to
specialized types when it comes to interpolation (which is what you and
adam are trying to get through). And therefor you can
On Saturday, 29 February 2020 at 00:57:54 UTC, aliak wrote:
Also another note, this tuple expansion should really not be
called string interpolation, since it does not result in a
string :/ It's more string expansion really.
Yeah, me and Steven agreed on this too in the other thread, and I
On Friday, 28 February 2020 at 19:16:08 UTC, Steven Schveighoffer
wrote:
On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright
wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it
On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote:
I don't know Swift, but this looks like the "generate strings and
concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an example of
how it could look
On Fri, Feb 28, 2020 at 05:45:35PM +, Atila Neves via
Digitalmars-d-announce wrote:
> On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote:
[...]
> > For all the trouble they've given us, built-in AA's is one of the
> > primary reasons I love D.
> > [...]
>
> The reason for C++
On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote:
On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via
Digitalmars-d-announce wrote: [...]
[...]
[...]
For all the trouble they've given us, built-in AA's is one of
the primary reasons I love D.
[...]
The reason for
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
Rust does not follow C syntax at all, so nobody will
reasonably expect it to have C semantics. D does follow it,
it's a feature, so people will
On Thursday, 27 February 2020 at 18:58:40 UTC, Walter Bright
wrote:
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
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an
example of how it could look like with D syntax:
auto a = 3;
auto b =
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 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 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 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 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
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 list of built-in types
indistinguishable from
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.
On Thursday, 27 February 2020 at 00:21:36 UTC, Walter Bright
wrote:
So would DIP1027.
We know. It is *almost* there, the format string idea is a good
one. But DIP1027 had a fatal flaw: it made type safety impossible.
One small change - wrapping the format string in a new type while
keeping
On 2/26/2020 5:19 AM, Steven Schveighoffer wrote:
We can do it without specifying that it's a template or the name of that
template.
That isn't what was proposed. I seriously suggest preparing a DIP. Bits and
pieces spread out over multiple posts and multiple threads is not working.
But
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 intermediate
variable.
On 2/26/2020 4:18 AM, FeepingCreature wrote:
But to be thrice fair, Adam/Steven's proposal would work with the minor
extension [...]
So would DIP1027.
You can also write:
print(format(i"I have $apple_cnt apples"));
void print(string s) { print_many(s); }
and get the behavior you're looking for.
On Wednesday, 26 February 2020 at 16:08:53 UTC, Adam D. Ruppe
wrote:
On Wednesday, 26 February 2020 at 15:41:48 UTC, Arine wrote:
Yah, what's unwanted about that?
To follow up on this, I expect a reply will be "the user ought
to know how the feature works". This isn't a realistic
On Wednesday, 26 February 2020 at 15:41:48 UTC, Arine wrote:
Yah, what's unwanted about that?
To follow up on this, I expect a reply will be "the user ought to
know how the feature works". This isn't a realistic expectation.
This is why I put in my little narrative in the new DIP, though
On Wednesday, 26 February 2020 at 09:57:58 UTC, Walter Bright
wrote:
On 2/25/2020 9:44 AM, H. S. Teoh wrote:
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
Writing that an implementation must refer to specific
templates
implies that the
On Wednesday, 26 February 2020 at 10:36:34 UTC, aliak wrote:
On Tuesday, 25 February 2020 at 16:04:59 UTC, Arine wrote:
``How to distinguish a different type? Use a different type.
No, is there another simpler way to do that instead?``
Is this really the line of thinking going on here? It
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but
I was just wondering if anyone managed to propose a way to
avoid this scenario with DIP1027?
void f(string s, int i = 0);
On Wednesday, 26 February 2020 at 09:57:58 UTC, Walter Bright
wrote:
Requiring the compiler to use a specific template that is not
specified by the user has no place in a language specification
(and therefore no place in a proposed language change).
I think more naturally in D code rather
On 2/26/20 4:57 AM, Walter Bright wrote:
On 2/25/2020 9:44 AM, H. S. Teoh wrote:
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
Writing that an implementation must refer to specific templates
implies that the behavior is customizable by the
On Wednesday, 26 February 2020 at 12:18:07 UTC, FeepingCreature
wrote:
But to be thrice fair, Adam/Steven's proposal would work with
the minor extension `f(i"hello $a".format)`/`f(i"hello
$a".to!string)`, in keeping with the trend of GC use requiring
explicit opt-in.
Actually, thanks to the
On Wednesday, 26 February 2020 at 11:13:12 UTC, Petar Kirov
[ZombineDev] wrote:
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
It is lowered to:
f("hello %s", a);
as designed. I don't know what's unwanted about it.
In all other languages with string interpolation
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but
I was just wondering if anyone managed to propose a way to
avoid this scenario with DIP1027?
void f(string s, int i = 0);
On Wednesday, 26 February 2020 at 10:02:15 UTC, Juraj Mojzis
wrote:
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
void print_many(string msg, int cnt = 1) {
foreach(i; 0 .. cnt) writeln(msg);
}
int apple_cnt = 4;
print_many(i"I have $apple_cnt apples.");
expected:
On Tuesday, 25 February 2020 at 16:04:59 UTC, Arine wrote:
``How to distinguish a different type? Use a different type.
No, is there another simpler way to do that instead?``
Is this really the line of thinking going on here? It seems
Walter has these arbitrary rules he's following which led
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but
I was just wondering if anyone managed to propose a way to
avoid this scenario with DIP1027?
void f(string s, int i = 0);
On 2/26/2020 2:02 AM, Juraj Mojzis wrote:
void print_many(string msg, int cnt = 1) {
foreach(i; 0 .. cnt) writeln(msg);
}
int apple_cnt = 4;
print_many(i"I have $apple_cnt apples.");
expected: I have 4 apples.
Doing what you want would require a runtime GC allocated string.
On 2/24/2020 4:07 PM, Steven Schveighoffer wrote:
To ensure that it cannot be intercepted.
See my reply to H.S. Teoh which addresses this.
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
void f(string s, int i = 0);
f(i"hello $a"); // silent unwanted bahviour.
?
It is lowered to:
f("hello %s", a);
as designed. I don't know what's unwanted about it.
void print_many(string msg, int cnt = 1) {
On 2/25/2020 9:44 AM, H. S. Teoh wrote:
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
Writing that an implementation must refer to specific templates
implies that the behavior is customizable by the user via modifying
those templates.
I think
On 2/25/2020 7:04 AM, Steven Schveighoffer wrote:
On 2/25/20 1:54 AM, Walter Bright wrote:
Were you proposing that an i"" be a different type? (DIP 1027 did not
assign a type to it at all.)
No, I proposed that the first element of the tuple be specified as a new
spec-defined type instead
On 2/25/2020 8:04 AM, Arine wrote:
Is this really the line of thinking going on here? It seems Walter has these
arbitrary rules he's following which led up to the impractical and buggy
solution that was DIP1027. Rules aren't meant to be followed blindly.
See what I mean about "no consensus
On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but I was just
wondering if anyone managed to propose a way to avoid this scenario with DIP1027?
void f(string s, int i = 0);
f(i"hello $a"); // silent unwanted bahviour.
?
It is lowered to:
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
> Writing that an implementation must refer to specific templates
> implies that the behavior is customizable by the user via modifying
> those templates.
I think this is where the misunderstanding
On 2/25/20 10:13 AM, Adam D. Ruppe wrote:
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
I should’ve been more specific I was wondering if the same could be
achieved without a introducing a new aggregate type!
Well, compiler magic, possibly with more @attributes. But that gets
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe
wrote:
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
[...]
Yes, that is the key impetus of our amendment, which I also
wrote up on a gist weeks ago and it
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
I should’ve been more specific I was wondering if the same
could be achieved without a introducing a new aggregate type!
Well, compiler magic, possibly with more @attributes. But that
gets far messier than a simple struct, so we
On 2/25/20 8:39 AM, Aliak wrote:
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
[...]
Yes, that is the key impetus of our amendment, which I also wrote up
on a gist weeks ago and it is now on github too!
On 2/25/20 1:54 AM, Walter Bright wrote:
On 2/24/2020 2:45 PM, Steven Schveighoffer wrote:
My inference of the discussion about this in the n.g. was the
templates would be used so users could customize the behavior to be
whatever they wanted.
By accepting a different type from string. In
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote:
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe
wrote:
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
[...]
Yes, that is the key impetus of our amendment, which I also
wrote up on a gist weeks ago and it
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
[...]
Yes, that is the key impetus of our amendment, which I also
wrote up on a gist weeks ago and it is now on github too!
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
This may have already been answered in the other threads, but I
was just wondering if anyone managed to propose a way to avoid
this scenario with DIP1027?
Yes, that is the key impetus of our amendment, which I also wrote
up on a gist
On Tuesday, 25 February 2020 at 07:07:50 UTC, Walter Bright wrote:
All DIP1027 did was turn an istring into a tuple. That's it.
The user can then do whatever they want with the tuple,
including overloading a custom function based on the tuple
arguments. DIP1027 did not actually do ANY
On 2/24/2020 8:24 PM, FeepingCreature wrote:
The behavior of formatting strings is *currently*
deferred to a template (std.format and co). This lets us do important decisions
at compiletime, like writing the format string to a file or a string buffer
piecewise without allocating memory. Why
On 2/24/2020 2:45 PM, Steven Schveighoffer wrote:
My inference of the discussion about this in the n.g. was the templates would
be used so users could customize the behavior to be whatever they wanted.
By accepting a different type from string. In other words, an overload.
This means you can
On Monday, 24 February 2020 at 22:11:08 UTC, Walter Bright wrote:
The semantics of an interpolated string must be defined by the
DIP, not deferred to some template. If the implementation of
those defined language features is done by a template, that is
an implementation choice, not part of the
On 2/24/20 5:45 PM, Steven Schveighoffer wrote:
My inference of the discussion about this in the n.g. was the
templates would be used so users could customize the behavior to be
whatever they wanted.
By accepting a different type from string. In other words, an overload.
I have a feeling
On Monday, 24 February 2020 at 21:41:22 UTC, aliak wrote:
Does that mean no betterC support if it's in druntime?
It would actually still work there because there is no actual
code to link, just a compile-time definition to look up.
For example, the name `string` itself is a druntime
On 2/24/20 5:11 PM, Walter Bright wrote:
On 2/24/2020 1:45 PM, Steven Schveighoffer wrote:
Our proposal is even more restrictive, as the template and its API are
actually defined by the language.
API is defined by the language, but not the behavior.
The language doesn't define my function's
On 2/24/2020 1:45 PM, Steven Schveighoffer wrote:
Our proposal is even more restrictive, as the template and its API are actually
defined by the language.
API is defined by the language, but not the behavior.
No. It's overloading, not AST macros. How can an overload affect the AST other
On 2/24/20 4:45 PM, Steven Schveighoffer wrote:
i"$apples and $%{d}bananas" will be transformed into:
Of course that should have read i"$apples and ${%d}bananas"
-Steve
On 2/24/20 4:41 PM, aliak wrote:
On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright wrote:
and proposed a lowering to:
> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
>
On 2/24/20 4:10 PM, Walter Bright wrote:
On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
How can you possibly arrive at this conclusion? We lower to templates
all the time.
The language is nowhere defined as lowering to specific templates. There
are indeed some lowerings to templates in
On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright
wrote:
and proposed a lowering to:
> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
> _d_interpolated_format_spec("%02x"))(),
On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright wrote:
and proposed a lowering to:
> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
> _d_interpolated_format_spec("%02x"))(), someByte)
Do you understand that `_d_interpolated_string` and
On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
How can you possibly arrive at this conclusion? We lower to templates all the
time.
The language is nowhere defined as lowering to specific templates. There are
indeed some lowerings to templates in the implementation of the language, but
On 2/24/2020 11:45 AM, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright wrote:
Having the compiler lower string interpolation to some hidden template is -
AST macros. We're not doing AST macros.
This is untrue.
Hidden user-defined semantics are not for D.
We
On 2/24/20 2:35 PM, Walter Bright wrote:
Having the compiler lower string interpolation to some hidden template
is - AST macros. We're not doing AST macros.
How can you possibly arrive at this conclusion? We lower to templates
all the time. By this definition all operator overloading in D is
On Monday, 24 February 2020 at 19:45:49 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright
wrote:
Having the compiler lower string interpolation to some hidden
template is - AST macros. We're not doing AST macros.
This is untrue.
Hidden user-defined
On 2/24/2020 9:24 AM, Arine wrote:
No [...]
Using unprofessional language will result in your posts being deleted. Please
stop.
On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright wrote:
Having the compiler lower string interpolation to some hidden
template is - AST macros. We're not doing AST macros.
This is untrue.
Hidden user-defined semantics are not for D.
We are NOT calling for this.
What, exactly,
Having the compiler lower string interpolation to some hidden template is - AST
macros. We're not doing AST macros.
Hidden user-defined semantics are not for D. Every language I'm familiar with
that supports it wound up with users creating their own completely undocumented
personal language
On 2/24/20 12:31 PM, H. S. Teoh wrote:
On Mon, Feb 24, 2020 at 10:41:16AM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
[...]
I will also note that we did something very similar with
switch(string), where prior to this the compiler did all the "heavy
lifting" of generating the
On 2020-02-24 09:51:16 +, Walter Bright said:
I talk it over with Atila after the review threads are done, then
decide. Voting is a terrible way to do engineering design, for many
reasons I can list if you like.
You don't need to, I'm not a fan of such a voting approach too. I just
On 2020-02-24 10:02:26 +, Mike Parker said:
The DIP review process is outlined here:
https://github.com/dlang/DIPs
The final decision rests with the language maintainers. Now, that means
Walter and Atila.
Thanks, and sorry for my ignorance... How about adding a note who the
"language
On Mon, Feb 24, 2020 at 10:41:16AM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
[...]
> I will also note that we did something very similar with
> switch(string), where prior to this the compiler did all the "heavy
> lifting" of generating the code to convert strings into
On Monday, 24 February 2020 at 09:51:16 UTC, Walter Bright wrote:
On 2/24/2020 12:43 AM, Robert M. Münch wrote:
I mean, people spend a lot of time thinking, making
suggestions, etc. and the end result is: we now have nothing.
Which, IMO is the worst result for all.
Not totally. I was unable
1 - 100 of 112 matches
Mail list logo
