Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 are you trying to get rid of this 
flexibility?


std.format is a library function, with its behaviors entirely defined by the 
library. It is not a core language feature.


There's nothing stopping writing a CTFE-able function for doing formatting. It 
doesn't need to be built in to the compiler.



As I understand it, the point of a format string template is to keep exactly 
this kind of flexibility in exactly the same places it is currently available to 
users, while simultaneously improving syntax legibility. To emphasize this 
again: the @gc format string would have *reduced* flexibility for 90% of our 
usecases (templated nogc/lowgc log library calls). As proposed, I don't see why 
I would have ever used it.


Steven's proposal is radically different from #DIP1027. It should be separately 
proposed as a coherent DIP, not in bits and pieces over several n.g. postings.


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 formatting at all.

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 have code that treats an interpolated string differently than 
a string. Overloads based on literal types are not a new feature.


Were you proposing that an i"" be a different type? (DIP 1027 did not assign 
a type to it at all.) This would be radically different from DIP 1027, and a 
large increase in complexity (adding any new basic types is a big deal and a 
very intrusive change, and is tough to justify).


This is different enough from DIP 1027 that it would merit a separate DIP.

DIPs for the core language specify only behaviors, not implementations. 
Implementation possibilities can be included in an advisory manner only. Note 
that nowhere in the (massive and complicated) C++ core language specification is 
there any description of how the compiler should be implemented. Writing that an 
implementation must refer to specific templates implies that the behavior is 
customizable by the user via modifying those templates.

Re: DIP 1027---String Interpolation---Format Assessment

[FeepingCreature via Digitalmars-d-announce]

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 DIP or spec.




I don't understand this. 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 are you trying to get rid of this flexibility?


As I understand it, the point of a format string template is to 
keep exactly this kind of flexibility in exactly the same places 
it is currently available to users, while simultaneously 
improving syntax legibility. To emphasize this again: the @gc 
format string would have *reduced* flexibility for 90% of our 
usecases (templated nogc/lowgc log library calls). As proposed, I 
don't see why I would have ever used it.

Re: GSOC 2020 projects

[RazvanN via Digitalmars-d-announce]

On Monday, 24 February 2020 at 17:43:41 UTC, Panke wrote:

On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote:

On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:

Hello everyone!

In a couple of days we should find out if The Dlang 
Foundation was accepted as a mentoring organization for 
Google Summer of Code 2020. If we get accepted, I think that 
we should have a list of priority projects that we should 
propose to students. I have started tagging what I find the 
most useful projects with the gsoc2020 tag [1]. If you want 
to help in this process you can:


[...]


Unfortunately, Dlang has not been accepted this year as a GSOC 
mentoring organization. Maybe we will have better luck next 
year,


Cheers,
RazvanN


Do we know why?


They simply notify if you have been accepted or not without 
offering any details, but I think that they want to offer a 
chance to everyone. Apart from big organizations that are offered 
spots every year, the small organizations are usually rotated, 
but we can't know for sure if there was something wrong with our 
application or they simply wanted to give someone else a chance.

Re: GSOC 2020 projects

[Mike Parker via Digitalmars-d-announce]

On Monday, 24 February 2020 at 18:00:15 UTC, rikki cattermole 
wrote:



Limited spots, somebody had to go.


That’s the only reason they ever give for rejection AFAIK.

Re: GSOC 2020 projects

[Bill Baxter via Digitalmars-d-announce]

The full list is here and there are lots of them:
https://summerofcode.withgoogle.com/organizations/?sp-page=2

I think gamefromscratch.com just pulled out a short list of ones that were
game-related there.

--bb

On Mon, Feb 24, 2020 at 10:05 AM rikki cattermole via
Digitalmars-d-announce  wrote:

> On 25/02/2020 6:43 AM, Panke wrote:
> > On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote:
> >> On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:
> >>> Hello everyone!
> >>>
> >>> In a couple of days we should find out if The Dlang Foundation was
> >>> accepted as a mentoring organization for Google Summer of Code 2020.
> >>> If we get accepted, I think that we should have a list of priority
> >>> projects that we should propose to students. I have started tagging
> >>> what I find the most useful projects with the gsoc2020 tag [1]. If
> >>> you want to help in this process you can:
> >>>
> >>> [...]
> >>
> >> Unfortunately, Dlang has not been accepted this year as a GSOC
> >> mentoring organization. Maybe we will have better luck next year,
> >>
> >> Cheers,
> >> RazvanN
> >
> > Do we know why?
>
> This is my guess:
>
>
> https://www.gamefromscratch.com/post/2020/02/20/GSoC-2020-Organizations-Announced.aspx
>
> Limited spots, somebody had to go.
>

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 from this comment that you are expecting that the 
compiler just literally lowers into the provided generated code, and 
leaves it up to the user to define the template. This is not the case.


The template will be defined in object.d, and the compiler will NOT 
COMPILE code that cannot find that template in the module object.d.


I would actually recommend that it lowers to:

.object._d_interpolated_string!(...), apples, bananas

To ensure that it cannot be intercepted.

-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe via Digitalmars-d-announce]

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 definition, 
but it still works in betterC because it does not link anything 
at run time. This is very similar.


There is a known bug 
 with betterC not 
allowing CTFE operations though, which imposes some unnecessary 
limitations, but we could and should fix that separately.


However, even with that bug, this proposal's i"" strings still 
partially work in betterC. And it will all work (except for the 
idup function, for obvious reasons) once that bug is fixed.

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 API, I do. I get to decide the 
types of my parameters, which ones are accepted, which ones aren't, what 
the names of my functions are, etc. Maybe you mean ABI?





No. It's overloading, not AST macros. How can an overload affect the 
AST other than to generate code specific to the type being accepted?


"generate code" is how.


This generates code (and AST):

int foo()
{
  return 1;
}

You can see it from the disassembly that a return statement is 
"generated". That's what I meant.






How is this an AST macro, but (string-literal, apples, bananas) not?


Because its behavior is defined by a template, not the language spec.


Not true. Both are defined by the language spec.



That's it. The whole definition of the template and whatever is simply 
implementation details.


No, it isn't. It's leaving things up to templates like "formatString".


The result of formatString is defined by the spec. It doesn't matter how 
the template actually generates it. The fact that there's a template 
involved has no bearing on what the result should be (which will be 100% 
defined as I said).


There are other instances of the compiler lowering things to templates, 
but the behavior is still defined by the language, not the template. The 
templates were not strictly necessary, they were just a convenience.


As is the case here.



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 DIP or spec.


This is exactly how the proposal is defined. There is no wiggle room for 
the template (or whatever we decide) to do anything but follow the spec 
exactly. You will never get alternative behavior from that type.



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 have code that treats an interpolated string 
differently than a string. Overloads based on literal types are not a 
new feature.


You can have foo(double) and foo(float), and foo(1.0) will result in 
something different than foo(1.0f).


-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 
than to generate code specific to the type being accepted?


"generate code" is how.



How is this an AST macro, but (string-literal, apples, bananas) not?


Because its behavior is defined by a template, not the language spec.


That's it. The whole definition of the template and whatever is simply 
implementation details.


No, it isn't. It's leaving things up to templates like "formatString".

There are other instances of the compiler lowering things to templates, but the 
behavior is still defined by the language, not the template. The templates were 
not strictly necessary, they were just a convenience.


Operator overloading is for user defined types, not builtin types.

---

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 DIP or spec.


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.

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 ",
> _d_interpolated_format_spec("%02x"))(), someByte)


Do you understand that `_d_interpolated_string` and 
`_d_interpolated_format_spec` are to be defined EXCLUSIVELY inside 
druntime?


There's nothing user-defined about this.


Does that mean no betterC support if it's in druntime?


It will be supported in betterC, as long as you have object.d available. 
This does not require any D features such as TypeInfo, ModuleInfo, 
static constructors, GC, etc.


-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 the implementation of the 
language, but those are NOT user defined templates, they are simply an 
implementation convenience.


typeid expressions lower to a TypeInfo object. That is a specific named 
object in object.d.


All we're saying is that it lowers to a specified type in object.d.


By this definition all operator overloading in D is AST macros.


Operator overloading is not supported for basic types. It's 
fundamentally different from what was proposed for interpolated strings.


Not at all. In fact, operator overloading lowers to a specific template 
on that type, which allows the user to write whatever code they want. 
This is how lowering works.


Our proposal is even more restrictive, as the template and its API are 
actually defined by the language.


Except that's not what's happening here. It's lowering to a template 
defined by the language, not the user. The user creates their own API 
(not language) by accepting such a template and unsurprisingly can 
react differently to different parameters to said function or template.


"creates their own API" => AST macros


No. It's overloading, not AST macros. How can an overload affect the AST 
other than to generate code specific to the type being accepted?


If you have an example that proves me wrong, I'd love to see it. How 
can this feature do something that is "like AST macros"?


Because the proposed templates modify the behavior of basic types. From 
the discussion:


 > i"$apples and ${%d}bananas"
 > =>
 > (__d_format_literal!(Format.init, " and ", Format("%d")),
  apples, bananas)


Where is the basic type modification here? i"..." is not a basic type, 
it's a string interpolation. It's never been in the language before. It 
doesn't translate into any basic type, it translates into a compile-time 
list of expressions.


How is this an AST macro, but (string-literal, apples, bananas) not?

---

Probably this is being misunderstood. Let me rephrase the proposal. 
Let's assume we agree on the format string grammar that was presented in 
the DIP:


i"$apples and $%{d}bananas" will be transformed into:

(interpolation_spec, apples, bananas)

Where interpolation spec will be an instance of a language-defined type. 
It will have the following API:


1. spec.formatString!(s) where s is a string, will be a compile-time 
constant format string (guaranteed to end in a null character) where all 
the interpolated expressions are handled as follows:
  a. If an interpolation expression is preceded with {x}, where x is 
the string literal in the braces, the entire interpolation expression 
will be replaced with the string literal x.
  b. If an interpolation expression is not preceded with {...}, then 
the entire interpolation expression will be replaced with the string `s` 
passed into the formatString member template.


2. spec.formatStringZ() will return the equivalent of 
`formatString!("%s").ptr`.
3. If all interpolations are determined to have a {...} specifier, then 
the interpolation_spec can be implicitly converted to a null-terminated 
const(char)*.


4. There will be an isInterpolationSpec(T) template added to object.d 
which will return true if the parameter T is an interpolation spec type.


---

That's it. The whole definition of the template and whatever is simply 
implementation details.


-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

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"))(), someByte)


Do you understand that `_d_interpolated_string` and 
`_d_interpolated_format_spec` are to be defined EXCLUSIVELY 
inside druntime?


There's nothing user-defined about this.


Does that mean no betterC support if it's in druntime?

Actually, was it different with the pure tuple approach in 
DIP1027?

Re: DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe via Digitalmars-d-announce]

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 
`_d_interpolated_format_spec` are to be defined EXCLUSIVELY 
inside druntime?


There's nothing user-defined about this.

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 
those are NOT user defined templates, they are simply an implementation convenience.



By this definition all operator overloading in D is AST macros.


Operator overloading is not supported for basic types. It's fundamentally 
different from what was proposed for interpolated strings.



Except that's not what's happening here. It's lowering to a template defined by 
the language, not the user. The user creates their own API (not language) by 
accepting such a template and unsurprisingly can react differently to different 
parameters to said function or template.


"creates their own API" => AST macros


If you have an example that proves me wrong, I'd love to see it. How can this 
feature do something that is "like AST macros"?


Because the proposed templates modify the behavior of basic types. From the 
discussion:


> i"$apples and ${%d}bananas"
> =>
> (__d_format_literal!(Format.init, " and ", Format("%d")),
 apples, bananas)

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 are NOT calling for this.



https://digitalmars.com/d/archives/digitalmars/D/DIP_1027--String_Interpolation--Final_Review_Discussion_Thread_335065.html#N335132

> * put the format literal in a wrapper type.
> i"$foo %"
> is translated to the tuple:
> __d_format_literal!("%s %%"), foo


and also you wrote:

> if we can
> all agree to amend it to put in the template thing we can fix
> everything. Even with just the one string arg, we can do a lot
> with it...

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)

and proposed:

> i"$foo %"
> is translated to the tuple:
> __d_format_literal!("%s %%"), foo
> struct __d_format_literal(string fmt) {
>  enum f = fmt;
>  alias f this;
> }

Re: Earcut polygon triangulation

[Ben Jones via Digitalmars-d-announce]

On Monday, 24 February 2020 at 19:15:13 UTC, JN wrote:

On Sunday, 23 February 2020 at 16:20:09 UTC, Ahmet Sait wrote:
Out of curiosity, why would you need to triangulate polygons 
instead of using stencil buffer? I'm assuming you're using 
OpenGL (or something similar) since you talked about your 
hobby game. Any advantage of triangulating shapes? 
(anti-aliasing maybe?)


Triangulation goes beyond rendering. I imagine this library 
might be useful when making a level editor for a DOOM-like 2.5D 
engine.


It's very poorly documented, but I wrote a delaunay refinement 
triangulator: https://github.com/benjones/dtriangulate .  It's 
mostly a reimplementation of Shewchuk's Triangle which is 
probably the most common delaunay triangulator.

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 AST 
macros. This means all the operations on associative arrays are AST 
macros. array dup and idup -- AST macro. destroy is an AST macro.




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 that nobody else can use or has the 
remotest interest in using.


Except that's not what's happening here. It's lowering to a template 
defined by the language, not the user. The user creates their own API 
(not language) by accepting such a template and unsurprisingly can react 
differently to different parameters to said function or template.


If you have an example that proves me wrong, I'd love to see it. How can 
this feature do something that is "like AST macros"?


If someone sees an i"abc" in the source code, they should be able to 
look in the language spec and know exactly what it does. They should not 
have to go trolling through imports looking for the definition of some 
template they never heard of.


I don't know where to begin here. The very argument rebuts itself -- The 
reason you look in the spec is to find out about the type of an 
interpolated string. Then you've heard of it. Are we supposed to only 
implement features that people have heard of before reading the spec? 
How would they have heard of it if they don't read the spec? Why do they 
have to go "trolling through imports" (whatever that means -- this 
template will be in object.d), and read the implementation? I mean, 
people compare 2 objects all the time without reading the definition for 
object.opEquals, I'm sure they could manage understanding that there's 
something different about interpolated strings, and still use writefln 
with them.


This whole response continues to imply that we do not understand each 
other's point of view.


-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[12345swordy via Digitalmars-d-announce]

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 semantics are not for D.


We are NOT calling for this.


What, exactly, do you think we're proposing?


I knew it. You needs an actual implementation here, to show 
walter what you are talking about. This reminds me of the whole 
mangle only discussion a while back. It took an actual PR for 
Walter to accept it instead of days arguing with him.


Let get to work on this.

-Alex

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

On 2/24/2020 9:24 AM, Arine wrote:

No [...]


Using unprofessional language will result in your posts being deleted. Please 
stop.

Re: DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe via Digitalmars-d-announce]

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, do you think we're proposing?

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

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 that nobody else can use or has the remotest interest in using.


Including me.

Exhibit A: 
https://www.boost.org/doc/libs/1_72_0/libs/preprocessor/doc/index.html

Everyone agrees, but says "but I know how to do AST macros in a sane way." 
They're wrong.


If someone sees an i"abc" in the source code, they should be able to look in the 
language spec and know exactly what it does. They should not have to go trolling 
through imports looking for the definition of some template they never heard of.

Re: Earcut polygon triangulation

[JN via Digitalmars-d-announce]

On Sunday, 23 February 2020 at 16:20:09 UTC, Ahmet Sait wrote:
Out of curiosity, why would you need to triangulate polygons 
instead of using stencil buffer? I'm assuming you're using 
OpenGL (or something similar) since you talked about your hobby 
game. Any advantage of triangulating shapes? (anti-aliasing 
maybe?)


Triangulation goes beyond rendering. I imagine this library might 
be useful when making a level editor for a DOOM-like 2.5D engine.

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

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 code to convert strings into integers. Now
it's done via a template which accepts all the strings as parameters.
I don't think it was a bad change, and I'm sure it increased compile
times and compiler memory usage.


No kidding, at one point it was making Phobos uncompilable except for
machines with huge gobs of RAM, because std.datetime had this gigantic
switch statement over, like, *every* locale name that exists in the
world, and it was causing a gigantic explosion of template bloat. I
think the solution that was eventually adopted was to replace that
switch with something else, which is not altogether a bad thing I
suppose, but still, it does put to question the practicality of having a
template generate code for a switch statement with >1000 string items.


The solution was to forward templates over a certain number of string 
elements to a single runtime function with an array created from the 
tuple list (which is a minimal wrapper) instead of a binary search via 
unrolled templates: 
https://github.com/dlang/druntime/blob/87bf88ba88d2926d7a470b5e126e0a5b1a1e266f/src/core/internal/switch_.d#L60-L73. 
It's unfortunate we even have to use CTFE to generate the immutable strings.


I wouldn't imagine a much different approach for this proposal as well 
-- convert to something useful at runtime and then call a runtime-only 
implementation.


As I said before, if we can make it so such "wrappers" are just 
forwarders, it would make the resulting code less bloated, and probably 
save on memory as well.


-Steve

Re: GSOC 2020 projects

[rikki cattermole via Digitalmars-d-announce]

On 25/02/2020 6:43 AM, Panke wrote:

On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote:

On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:

Hello everyone!

In a couple of days we should find out if The Dlang Foundation was 
accepted as a mentoring organization for Google Summer of Code 2020. 
If we get accepted, I think that we should have a list of priority 
projects that we should propose to students. I have started tagging 
what I find the most useful projects with the gsoc2020 tag [1]. If 
you want to help in this process you can:


[...]


Unfortunately, Dlang has not been accepted this year as a GSOC 
mentoring organization. Maybe we will have better luck next year,


Cheers,
RazvanN


Do we know why?


This is my guess:

https://www.gamefromscratch.com/post/2020/02/20/GSoC-2020-Organizations-Announced.aspx

Limited spots, somebody had to go.

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

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 
added a bunch of variants as I didn't know how the process works nor 
who is involved at what step.


Not totally. I was unable to convince people that printf format 
validation was an orthogonal feature. So I went ahead and implemented 
that to show it had nothing to do with the proposal:


https://github.com/dlang/dmd/pull/10812

It turned out kinda sweet, and found a huge number of latent bugs in 
our own code, proving we shoulda done that long ago :-) Bad printfs 
turned out to be much more common than I'd anticipated.


Proving by showing the results... Ok, looking forward how things develop.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

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 maintainers" are?


... If that proposal and its review manage to convince Walter and 
Atila, then the feature gets in.


Ok. I understand.

The DIP process is one way to approach that. It allows everyone to 
provide feedback and influence the drafting of the DIP. That requires 
convincing the DIP author to revise the DIP and ultimately convincing 
the language maintainers to accept it. It means there's a high barrier 
for acceptance, but in my own opinion that's how it should be.


I agree. My impression and point was (after following the topic loosly) 
that the DIP might be close to find a good solution and that it was 
suddenly withdrawn. But anyway...



--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: GSOC 2020 projects

[Panke via Digitalmars-d-announce]

On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote:

On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:

Hello everyone!

In a couple of days we should find out if The Dlang Foundation 
was accepted as a mentoring organization for Google Summer of 
Code 2020. If we get accepted, I think that we should have a 
list of priority projects that we should propose to students. 
I have started tagging what I find the most useful projects 
with the gsoc2020 tag [1]. If you want to help in this process 
you can:


[...]


Unfortunately, Dlang has not been accepted this year as a GSOC 
mentoring organization. Maybe we will have better luck next 
year,


Cheers,
RazvanN


Do we know why?

Re: DIP 1027---String Interpolation---Format Assessment

[H. S. Teoh via Digitalmars-d-announce]

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 integers. Now
> it's done via a template which accepts all the strings as parameters.
> I don't think it was a bad change, and I'm sure it increased compile
> times and compiler memory usage.

No kidding, at one point it was making Phobos uncompilable except for
machines with huge gobs of RAM, because std.datetime had this gigantic
switch statement over, like, *every* locale name that exists in the
world, and it was causing a gigantic explosion of template bloat. I
think the solution that was eventually adopted was to replace that
switch with something else, which is not altogether a bad thing I
suppose, but still, it does put to question the practicality of having a
template generate code for a switch statement with >1000 string items.


> We shouldn't shy away from this type of stuff, but rather invest in
> making it better.
[...]

Agreed.  I think after newCTFE is finally merged, the next major item to
tackle is how to improve the performance of template-heavy code.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

Re: DIP 1027---String Interpolation---Format Assessment

[Arine via Digitalmars-d-announce]

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 to convince people that printf format 
validation was an orthogonal feature. So I went ahead and 
implemented that to show it had nothing to do with the proposal:


https://github.com/dlang/dmd/pull/10812


With the way that the DIP you wrote up, it really isn't 
orthogonal. How people *expect* string interpolation to work is 
like this:


   float a;
   int b;

   printf(i"$a $b"); // should just work


What your DIP did is this:


   float a;
   int b;

   // printf(i"$a $b"); becomes:
   printf("%s %s", a, b);

   printf(i"${%d}a ${%f}b"); // need to do formatting on your own 
anyways


The only way you wouldn't want printf format validation for such 
a feature is if you are fine with buggy code. You literally still 
require the user to format the strings themselves, this is no 
different than simply using printf. And guess what:


It turned out kinda sweet, and found a huge number of latent 
bugs in our own code, proving we shoulda done that long ago :-) 
Bad printfs turned out to be much more common than I'd 
anticipated.


No shit.

Re: DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe via Digitalmars-d-announce]

On Monday, 24 February 2020 at 16:22:22 UTC, Atila Neves wrote:
Thanks for the detailed write-up, there are a lot of good 
things here.


We talked about this in the other thread, too.

I doubt the one template here will be a big deal. My experience 
is templates get bad when we use them in loops or recursion. One 
line of user code can easily expand a dozen separate 
instantiations.


Like in my jni thing, this one line: `DTypesToJni!(typeof(args))` 
expands to (args.length * 3) different templates (the impl is 
basically `alias it = AliasSeq!(convert!T[0], convert![T .. 
$])`). There's certainly the possibility it will be less, like 
foo(int, int) will be able to reuse that int one, but it is still 
work for the compiler to do.


Various std.typecons type things and std.algorithm builders can 
easily grow hugely - a range pipeline has templates returning 
templates based on templated input types.


But back to mine, since its intent is to be used in a 
__traits(allMembers) loop with different things each time, it can 
easily be hundreds of templates in two lines of user code.


Now, contrast that to a tuple builder literal, which has no 
internal recursion at all. It is just one instantiation. Even in 
a loop we might use in code generation:


static foreach(member; __traits(allMembers, T))
  mixin(i"void $member() {}".idup);


Well, each unique i"" only gives one template. That call to idup 
is a second one. So we are at two instantiations... no matter 
what the input is.



It is certainly possible to write code that does a bad job with 
it. But it is harder than you think. Even doing what I so often 
tell people not to do:



static foreach(member; __traits(allMembers, T))
  mixin(i"$(__traits(getMember, T, member).stringof) $member() 
{}".idup);



stuff like that with stringof... is still only two instantiations 
for any T. The string is still a literal and the types of the 
arguments are still the same.


I think you'd have to actively try to make more than a constant 
two template instantiations out of the i"" string. Natural uses 
will tend to give just one for the string itself and one for the 
function you call with it (which btw is already a cost we're 
paying - writeln's variadic template list does the same as it is! 
So it is really an increase of one template per use, constant. No 
multiplicative growth like with typical recursive templates, or 
worse as we see in the really pathological cases.)

Re: DIP 1027---String Interpolation---Format Assessment

[Atila Neves via Digitalmars-d-announce]

On Monday, 24 February 2020 at 15:41:16 UTC, Steven Schveighoffer 
wrote:

On 2/24/20 4:38 AM, Atila Neves wrote:
There's also the practical question of template instantiations 
and compile times even if the DIP that was being discussed 
were to be modified in the way suggested.


I want to actually explore this.




Thanks for the detailed write-up, there are a lot of good things 
here.

Re: DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/24/20 4:38 AM, Atila Neves wrote:
There's also the practical question of template instantiations and 
compile times even if the DIP that was being discussed were to be 
modified in the way suggested.


I want to actually explore this.

There would be one template instantiation (probably) per usage. Not only 
that, but the function being called would also have a separate template 
instantiation per usage. This could potentially explode code to 
undesirable levels.


However, we have some possible mitigation techniques. For example, 
writefln should validate the format specifiers against the parameters, 
and then call the real writefln with a format string literal.


Second, I would suggest revisiting the idea of "temporary templates" 
that I talked about here: 
https://forum.dlang.org/post/qrjls8$13je$1...@digitalmars.com. If the 
"shim" call is inlined, and the template removed, then you are simply 
left with the call to the standard writefln.


This does not reduce compile-times. But I'm hoping we have an answer in 
the newCTFE update. We should really explore more ways to make 
generative code more palatable. This is D's strength.


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 integers. Now it's done via 
a template which accepts all the strings as parameters. I don't think it 
was a bad change, and I'm sure it increased compile times and compiler 
memory usage. We shouldn't shy away from this type of stuff, but rather 
invest in making it better.


Finally, I'd say that I would really prefer a tiny bit of compiler magic 
here. I would love for the template that defines the format string to 
devolve directly into a string literal if that's the usage -- 
potentially without actually instantiating the template. It can be a 
better option if we are super-concerned about template slowdown.


-Steve

Re: DIP 1027---String Interpolation---Format Assessment

[bachmeier via Digitalmars-d-announce]

On Monday, 24 February 2020 at 08:43:57 UTC, 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.


We don't have nothing. There's an option value of not making a 
decision at this time. Once you decide to go forward with a 
string interpolation proposal, you're deciding not to go forward 
with any other similar proposal for many years, or even forever. 
This is IMO a minor feature (not a big deal if we don't have it). 
If you're going to do it, do it right. In some cases, there's 
really no way to know until you have a formal proposal and 
discuss the heck out of it whether it's worth going forward.

Re: DIP 1027---String Interpolation---Format Assessment

[Basile B. via Digitalmars-d-announce]

On Monday, 24 February 2020 at 10:02:26 UTC, Mike Parker 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 at all. In this case, as the DIP author, Walter could have 
chosen to revise the DIP with a new implementation. He chose 
not to. He wasn't persuaded by the arguments in the thread.


Yeah, not to mention that in first place I think that he made a 
DIP for named args because the commuity was unable to formulate a 
good propostion, while he was himself not "pro-named args"... 
(maybe, I think i read this in the past)

Re: DIP 1027---String Interpolation---Format Assessment

[Mike Parker via Digitalmars-d-announce]

On Monday, 24 February 2020 at 08:43:57 UTC, Robert M. Münch 
wrote:






Out of curiosity, how and who makes such a decision? Is there a 
voting? Is there a committee? Is there a structured pro/con 
overview and highlight of blocking-points that need to be 
resolved?


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.




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 at all. In this case, as the DIP author, Walter could have 
chosen to revise the DIP with a new implementation. He chose not 
to. He wasn't persuaded by the arguments in the thread. Anyone 
else in the community is free to submit an alternative DIP for 
the same feature. Adam Ruppe has already done so:


https://github.com/dlang/DIPs/pull/186

If that proposal and its review manage to convince Walter and 
Atila, then the feature gets in.




As a community with highly skilled people I think there should 
be a way to come to a good solution, not only a good enough. If 
not, this doesn't shed light on D and the community...


The DIP process is one way to approach that. It allows everyone 
to provide feedback and influence the drafting of the DIP. That 
requires convincing the DIP author to revise the DIP and 
ultimately convincing the language maintainers to accept it. It 
means there's a high barrier for acceptance, but in my own 
opinion that's how it should be.

Re: DIP 1027---String Interpolation---Format Assessment

[Walter Bright via Digitalmars-d-announce]

On 2/24/2020 12:43 AM, Robert M. Münch wrote:
Out of curiosity, how and who makes such a decision? Is there a voting? Is there 
a committee? Is there a structured pro/con overview and highlight of 
blocking-points that need to be resolved?


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.



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 to convince people that printf format validation was 
an orthogonal feature. So I went ahead and implemented that to show it had 
nothing to do with the proposal:


https://github.com/dlang/dmd/pull/10812

It turned out kinda sweet, and found a huge number of latent bugs in our own 
code, proving we shoulda done that long ago :-) Bad printfs turned out to be 
much more common than I'd anticipated.



As a community with highly skilled people I think there should be a way to come 
to a good solution, not only a good enough. If not, this doesn't shed light on D 
and the community...


Community input is what the review threads are for. Consensus on a good solution 
did not emerge.

Re: DIP 1027---String Interpolation---Format Assessment

[Atila Neves via Digitalmars-d-announce]

On Sunday, 23 February 2020 at 18:57:55 UTC, Adam D. Ruppe wrote:

On Sunday, 23 February 2020 at 16:22:46 UTC, Mike Parker wrote:
The decision was primarily influenced by the lack of consensus 
over the implementation and the syntax demonstrated in the two 
review threads.


That's not true, we had consensus minus one - the community 
rallied around just one small tweak to the proposal.


I don't think that the proposed change was one small tweak. Even 
if it were, the DIP that just got rejected didn't have it.


There's also the practical question of template instantiations 
and compile times even if the DIP that was being discussed were 
to be modified in the way suggested.


Would you have preferred the DIP were accepted "as-was"?

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

On 2020-02-23 16:22:46 +, Mike Parker said:

DIP 1027, "String Interpolation", has been rejected. The decision was 
primarily influenced by the lack of consensus over the implementation 
and the syntax demonstrated in the two review threads. As the DIP 
author, Walter also rejected the suggestion to go with an 
implementation that resolves to a library template. He sees that as 
equivalent to AST macros, a feature which he has previously rejected.


https://github.com/dlang/DIPs/blob/4be15bd40381667c0ab1c0aef360d0daa4b8c82c/DIPs/rejected/DIP1027.md 



Out of curiosity, how and who makes such a decision? Is there a voting? 
Is there a committee? Is there a structured pro/con overview and 
highlight of blocking-points that need to be resolved?


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.


As a community with highly skilled people I think there should be a way 
to come to a good solution, not only a good enough. If not, this 
doesn't shed light on D and the community...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster