Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Tuesday, 18 July 2017 at 05:11:30 UTC, Kai Nacke wrote:
In master there is already some OpenBSD support. Some time ago 
I worked on druntime support but I still need to finish this. 
Mostly there is nothing magic here - just translating the 
header files. The only non-obvious work is required for the 
module/shared library stuff (in rt.sections). If there is an 
OpenBSD expert around who can help here it would be nice.


Maybe talk to OpenBSD porters on their mailing list. I'll 
put my stuff on github as soon as I can.

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Monday, 17 July 2017 at 17:18:23 UTC, Joakim wrote:
Unfortunately, dmd has not kept porters in mind and hasn't 
kept the C++ version updated, or kept a workflow that enables 
easy bootstrapping:


http://forum.dlang.org/thread/xgtbpcvbikxlilanr...@forum.dlang.org

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could invoke 
to bootstrap a new dmd.  You may run into issues related to 
D/C++ integration when building the latest dmd, as that 
hasn't been tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it 
will likely require some work, though likely not a lot.


I've already tried building 2.067 druntime by mistake and 
run into problems. Most are resolvable by just adding 
TARGET_OPENBSD next to TARGET_FREEBSD. But yeah, it's gonna 
take some work. I want it because I'm using OpenBSD as my 
main OS and I have a project that I want to port to D.


Btw I should've built the `install` target (got confused by 
the wiki). Now I get:


cp: ../ini/openbsd/bin64/dmd.conf: No such file or directory

which is more understandable.

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Monday, 17 July 2017 at 09:58:42 UTC, Joakim wrote:
The last dmd we released that was written in C++ was 2.067, for 
which you can still check out the branch.  You'd have to 
build that bootstrap compiler 2.067 first, then worry about the 
latest dmd.


Since we don't regularly build for OpenBSD, it's 
possible that support has slipped behind.  Usually, it's 
as easy as adding OpenBSD to a couple more #ifdefs, but 
sometimes you need to adapt the dmd source also for a rarely 
used platform like OpenBSD.


I managed to build the bootstrap dmd without any trouble. Btw the 
wiki page doesn't mention that the dependency is *GNU* Make 
which is typically installed as gmake on BSDs. Then I tried 
building the new dmd and got (in dmd/src):


CC=c++ dmd -of../generated/openbsd/release/64/idgen ddmd/idgen.d
Error: cannot find source code for runtime library file 
'object.d'
   dmd might not be correctly installed. Run 'dmd 
-man' for installation instructions.

   config file: /etc/dmd.conf
Specify path to file 'object.d' with -I switch
gmake[1]: *** [posix.mak:437: 
../generated/openbsd/release/64/idgen] Error 1


Now I'm trying to figure out the /etc/dmd.conf business. I 
found ini/freebsd/bin64/dmd.conf in the 2.067 dmd folder so I 
guess I'll start from there. Thanks for the help so far.

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Sunday, 16 July 2017 at 21:37:12 UTC, Seb wrote:

How about simply building the bootstrap binary yourself then?
I think 2.067 is the last version that's still written in 
C++:


https://github.com/dlang/dmd/tree/2.067


Yep, that should work. I believe this should be put somewhere on 
the wiki because otherwise bootstrapping is hard to figure out.



PS: Do you manually insert the HTML codes? They are escaped.


I noticed them added after a redirect to the captcha page 
(I'm using tor).

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Sunday, 16 July 2017 at 19:47:20 UTC, Seb wrote:
Auto-bootstrapping is __only__ used if no host compiler is 
found on the system.
This should only happen on esoteric platforms (not intended as 
an offense) like yours.


So I should use digger then? I looked through its repo briefly 
and I can't really tell if I'm gonna run into the same 
issue or not.
I guess another option is to build GDC and then use it to build 
DMD.



In any case, I submitted a PR to use SSL for AUTO_BOOSTRAP:

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


Thanks.

Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

I did some googling (well, duckduckgoing) and found a few posts 
on this forum indicating that this could work. So I gave it a try 
and followed https://wiki.dlang.org/Building_under_Posix
The build failed because src/posix.mak in the dmd repo was trying 
to download 
http://downloads.dlang.org/releases/2.x/2.072.2/dmd.2.072.2.openbsd.tar.xz which doesn't exist. What do I do now?


OTOH it's a good thing that the build failed. When I saw 
http:// instead of https:// in the console output I went to check 
what the makefile was doing and - wait for it - it was trying to 
download an executable from the internet and run it. I 
couldn't believe my eyes. I mean, you sure can use an 
unencrypted channel but then you need some kind of cryptographic 
signature to verify the downloaded file. I tried the above with 
2.074.1 (the latest stable) but the trunk version has this too.

Re: Weird dmd error?

[Anonymous via Digitalmars-d]

On Monday, 7 November 2016 at 12:31:57 UTC, Anonymous wrote:
On Monday, 7 November 2016 at 11:57:48 UTC, Andrea Fontana 
wrote:

On Monday, 7 November 2016 at 10:57:49 UTC, Anonymous wrote:
Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another 
semantic pass would be required. But in this case you 
couldn't determine how many passes would be necessary so 
there would be a  complexity problem in the compiler.


But it's not really the same, error in my case is inside 
druntime.

In your example errors are inside my code.


i'm on a 2071.2 frontend now, my comments are based on this.
are you on 2072 ?


oh no yet another 2.072 regression !

Re: Weird dmd error?

[Anonymous via Digitalmars-d]

On Monday, 7 November 2016 at 11:57:48 UTC, Andrea Fontana wrote:

On Monday, 7 November 2016 at 10:57:49 UTC, Anonymous wrote:
Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another 
semantic pass would be required. But in this case you couldn't 
determine how many passes would be necessary so there would be 
a  complexity problem in the compiler.


But it's not really the same, error in my case is inside 
druntime.

In your example errors are inside my code.


i'm on a 2071.2 frontend now, my comments are based on this.
are you on 2072 ?

Re: Weird dmd error?

[Anonymous via Digitalmars-d]

On Monday, 7 November 2016 at 09:58:08 UTC, Anonymous wrote:
On Monday, 7 November 2016 at 08:34:55 UTC, Andrea Fontana 
wrote:


--- test.d
void* test (ssize_t );
import core.sys.posix.unistd;
---

Try to run:
dmd test.d

It says:
/usr/include/dmd/druntime/import/core/sys/posix/sys/types.d(100): Error: 
undefined identifier 'c_long'


It looks normal but it's not documented. It's just that the 
import is not yet known in the scope.


To be clearer, the problem is the same with:

void main()
{
foo;
void foo(){}
}

Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another semantic 
pass would be required. But in this case you couldn't determine 
how many passes would be necessary so there would be a  
complexity problem in the compiler.

Re: Weird dmd error?

[Anonymous via Digitalmars-d]

On Monday, 7 November 2016 at 08:34:55 UTC, Andrea Fontana wrote:


--- test.d
void* test (ssize_t );
import core.sys.posix.unistd;
---

Try to run:
dmd test.d

It says:
/usr/include/dmd/druntime/import/core/sys/posix/sys/types.d(100): Error: 
undefined identifier 'c_long'


It looks normal but it's not documented. It's just that the 
import is not yet known in the scope. It 's like:


void main(string[] args)
{
writeln();
import std.stdio;
}

But

void main(string[] args)
{
writeln();
}
import std.stdio;

works because the symbol lookup succeeds in the parent scope.

For your example to work, another semantic pass would necessary.

Re: RC buffer

[anonymous via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.



Andrei


BTW about this PR: why RCString an not more generally RCArray ?

Re: Windows vs UTF-8 (issue 15845)

[anonymous via Digitalmars-d]

On Sunday, 3 April 2016 at 22:48:21 UTC, Adam D. Ruppe wrote:
What happens if you give it a 4 char buffer? I imagine it would 
work fine then in all cases. It seems to for me.


Doesn't seem to work for me.

The exact code I tested:

import std.stdio;
import std.exception: enforce;
import core.sys.windows.windows;

void main()
{
SetConsoleCP(65001);
SetConsoleOutputCP(65001);

uint readBytes;
ubyte[4] c;
ReadFile(GetStdHandle(STD_INPUT_HANDLE), c.ptr, c.length,
&readBytes, null).enforce();
writeln(readBytes, " ", c[]);
}


When I enter "a", it prints "3 [97, 13, 10, 0]".
When I enter "ä", it prints "0 [0, 0, 0, 0]".

I've also tried even larger buffers. Same result.

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On Wednesday, 17 February 2016 at 20:11:10 UTC, anonymous wrote:

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136


No response to that either. I've also tried emailing two other 
addresses and Twitter. Nothing. What now?

Re: Official compiler

[anonymous via Digitalmars-d]

On 18.02.2016 21:24, David Nadlinger wrote:

But please don't make up argument trying to rationalize whatever
personal decision somebody else made. You could literally copy LLVM
source code into your application and sell it as a closed-source product
without risking any copyright problems (if you comply with the very
modest attribution clause of the license).


LLVM's license isn't the supposed problem. DMD's license is. You cannot 
copy DMD backend code to LLVM. By not contributing to other compilers, 
Walter stays in the clear in that regard. At least, that's how I 
understand the argument.

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136

[dlang.org] Getting the ddox pages out of limbo

[anonymous via Digitalmars-d]

We currently have two differently generated versions of the library 
documentation on dlang.org:


1) dlang.org/phobos/* (and dlang.org/phobos-prerelease/*) is generated 
by dmd's Ddoc functionality. These are the official docs, part of the 
"Documentation" section.


2) dlang.org/library/* (and dlang.org/library-prerelease/*) is generated 
by ddox (). Once upon a time, 
these docs were supposed to become official, replacing the other ones. 
Currently, they're in an unfortunate state of beta-forever.


ddox has a number of issues that make it currently not feasible to just 
switch over:


* Macro for "path to base of docs"?
https://github.com/rejectedsoftware/ddox/issues/87

* macros from parent scopes are not known in child scopes
https://github.com/rejectedsoftware/ddox/issues/116

* treating of underscore not consistent with dmd
https://github.com/rejectedsoftware/ddox/issues/117

There may be more.

Now, is the plan still to make the switch to ddox for the official 
documentation? Is anyone actually working towards that goal?


If not, maybe we should get rid of the ddox pages, at least for the time 
being. Currently, I think they do more harm than good: They confuse 
people who find them through google, and they drain maintenance resources.


Regarding google, hiding them via robots.txt could be a milder 
alternative to outright deleting them.


And then there's Adam D. Ruppe's . No idea how 
that plays into the whole mess we're in.

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On 10.02.2016 22:37, CraigDillabaugh wrote:

I know I can take the logo from the website and blow it up, but it is
pretty small and enlarging it so much will result in a pretty awful
looking image.


It's an SVG file, so enlarging should work beautifully. If you're having 
trouble with it, I can upload a larger SVG or PNG version.


Is 256x256 the ideal format? Does it need to be square? The logo on the 
site is more wide than high. Do you want it cropped or centered?

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On 10.02.2016 21:38, Ola Fosheim Grøstad wrote:

Ask for a Creative Commons license?


I've shot him an email.

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On 10.02.2016 17:49, Ola Fosheim Grøstad wrote:

If you guys are going to create a
new logo based on the old one, you probably should clear it with the
original creator. On his website he has give us use rights for
non-commercial use, but not rights to create derivative works...


The new logo is not part of the pull request. It's already on the site. 
If there's a legal problem, we should probably revert that.


The exact text on the site of the original author [1] is

COPYRIGHT © SUKIMASHITA 2006
ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED.

I'd understand that to allow derivative works, but disallow selling 
them. I'm not a lawyer, though.


If those terms don't allow us to mess with the logo, what kind of 
statement or license do we need from the author?



[1] http://media.sukimashita.com/d/

Re: Safe cast away from immutable

[anonymous via Digitalmars-d]

On 08.02.2016 22:14, Iakh wrote:

Is all prams being const(but not immutable) not enough for
function to be Pure?


The hidden `this` parameter must be const, too. And mutable indirections 
in the return type must be considered.


This article explains it in detail:
http://klickverbot.at/blog/2012/05/purity-in-d/

Re: Type safety could prevent nuclear war

[anonymous via Digitalmars-d]

On 05.02.2016 00:47, tsbockman wrote:

You can do the same thing in D if you try, but it's not natural at all
to use `extern(C)` for *internal* linkage of an all-D program like that.

Any competent reviewer would certainly question why you were using
`extern(C)`; this scores much lower in "underhanded-ness" than the
original C program.


We do have a lot of bindings to C libraries, though. When there's a 
wrong alias in one of them, you have the same scenario.



Even so, I think that qualifies as a compiler bug or a hole in the D spec.


Can anything be done about it? The compiler simply has no way to verify 
declarations, has it?

Re: Type safety could prevent nuclear war

[anonymous via Digitalmars-d]

On 04.02.2016 23:57, tsbockman wrote:

http://www.underhanded-c.org/#winner

Actually, I'm surprised that this works even in C - I would have
expected at least a compiler (or linker?) warning; this seems like it
should be easy to detect automatically.


You can do the same thing in D, using extern(C) to get no mangling:

main.d:

alias float_t = double;
extern(C) float_t deref(float_t* a);
void main()
{
import std.stdio: writeln;
float_t d = 1.23;
writeln(deref(&d)); /* prints "1.01856e-314" */
}


deref.d:

alias float_t = float;
extern(C) float_t deref(float_t* a) {return *a;}


Command to build and run:

dmd main.d deref.d && ./main

Re: Interested in D, spec confuses me.

[anonymous via Digitalmars-d]

On 02.02.2016 20:50, Bambi wrote:

Making the return value immutable is a very different thing from making
every value of the object immutable to the method alone.


Sure it's a different thing, but the meaning of "immutable" is the same.

By the way, it's not that the object's fields are made immutable for the 
method, but the method can only be called on immutable objects.



These are
different meanings. It reads like a redundancy but has different
meanings. This isn't good in my eyes.


I don't see how it reads like a redundancy. Surely, you don't expect a 
redundancy in this:


void f(immutable int[] a, immutable int[] b);

The other signature is no different. Two occurrences of "immutable", 
applying to two different things.


I agree that it can be unclear to newbies what exactly is immutable when 
a method is marked immutable, but the meaning of the keyword is the same 
as elsewhere. Using another word there would be more confusing.

Re: Interested in D, spec confuses me.

[anonymous via Digitalmars-d]

On 02.02.2016 15:36, Bambi wrote:

The example snippet ' immutable(int[]) bar() immutable {} ' brings back
bad memories of redundant declarations of the style ' Object object =
new Object(); '. And homonyms in programming languages seem like a bad
idea in general.


"immutable" is not a homonym here. It means the same thing ("cannot ever 
change"). And it's not redundant either, as the two instances apply to 
different targets. It's clear what the first "immutable" ties to: It 
qualifies the return type. The second one is less clear: It qualifies 
the type of the object, meaning the method can only be called on an 
immutable object.


Leaving either of them out changes the meaning of the signature:
`int[] bar() immutable {}` - Return type is mutable now.
`immutable(int[]) bar() {}` - Object type is mutable now. I.e., this 
method can be called on a mutable object, and it cannot be called on an 
immutable object.

Re: CTFE thoughts & functional approach

[anonymous via Digitalmars-d]

On 02.02.2016 09:27, Robert M. Münch wrote:


==> BEGIN

[...]

enum A {afoo, bfoo, cfoo};


(Aside: In D no semicolon is needed here.)


string generateEnums(T...)(string type){
string code = "enum " ~ type ~ " {";

// this is a static foreach (compile time)
foreach(m; T){
  debug pragma(msg, m ~ ","); // check what code we get at compile time
  code ~= m ~ ",";
}

return(code ~ "}");


(Aside: Those parentheses are misleading. return is not a function.)


}

int main(){

[...]

mixin(generateEnums!members1("B"));
B switch_var_b = chomp(user_input).to!B; // get rid of terminating
chars


[...]

}

<== END


I'm not saying that everything is perfect as it is, but that code can be 
made nicer with what we have right now:



template generateEnums(string[] members)
{
// 'join' variant:
import std.array: join;
mixin("enum generateEnums {" ~ members.join(",") ~ "}");

// 'format' variant:
// import std.format;
// mixin(format(q{ enum generateEnums {%-(%s, %)} }, members));
}

void main()
{
alias B = generateEnums!([members1]);
B switch_var_b = chomp(readln()).to!B;
/* ... */
}



How about being able to write something like "ensure_final_switch B;"
and have this call a CTF that generates the necessary code and has
access to tool for building D structured code, AST etc.? And has a
compile-time state I can later access in a upcoming CTF.


So you're asking for AST macros, I suppose. There are two DIPs for them:

http://wiki.dlang.org/DIP50 - AST Macros
http://wiki.dlang.org/DIP78 - AST Macros Lite

I don't know where they stand, as I'm not really interested in the whole 
thing, but maybe one of those matches your vision.


If that's not what you have in mind, please be more concrete about what 
you think of. Maybe show some pseudo code showing how you'd like to be 
able to solve the example of generating enums.

Re: CTFE thoughts & functional approach

[anonymous via Digitalmars-d]

On Sunday, 31 January 2016 at 13:59:06 UTC, Robert M. Münch wrote:

I like CTFE and the meta programming idea for languages like D.

However, I'm wondering why most (everyone?) is trying to do 
meta-programming using the same language as the one getting 
compiled. IMO the use-cases a pretty different and doing CTFE, 
code-generation etc. needs some other approach. If you look at 
all the strange template syntax, strange hacks etc. it's all 
far from being obvious.


You're conflating CTFE with the other meta programming tools 
here. CTFE is the same language as run-time D, but it doesn't 
have strange template syntax. Templates, static if, __traits, 
etc. have strange syntax, but they're sort of a different 
language already.


Are you maybe wishing for a nicer alternative to templates, etc?

Why not have a CTL (compile-time-language) that has access to 
some compiler internals, that follows a more functional 
concept? We are evaluating sequences of things to generate 
code, include / exclude code etc.


From my experience with the different approaches, functional 
thinking is much better suited and simpler to use for CTFE 
goals.


IMO that would really be a big step ahead. Because you know a 
hammer, not everything is a nail...


I think this is too vague to lead anywhere. At least you should 
identify specific problems with D's toolset. And if you have 
concrete ideas for improvements, you should desribe them in more 
detail, spelling out how they improve upon the status quo.


If you want to have an entirely different meta programming 
system, then you should show how it would look like, and how it 
would be better than the status quo. I don't think anyone can 
make much of "make it more functional". Also, when it's 
fundamentally different from what we have now, then I don't see 
it getting into D at the moment. The language is not in a phase 
of designing fundamentals.

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 00:46, anonymous wrote:

http://i.imgur.com/eJaKFtx.png

[...]

For dlang.org, I'd choose the version with the wide background arc. I
think it looks nice on the menu bar, and it puts a little more emphasis
there than just the core shape. But just the core shape looks fine, too.


I made a pull request for the wide one (the third one from the top):

https://github.com/D-Programming-Language/dlang.org/pull/1212

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 20:08, WebFreak001 wrote:

Original: https://i.imgur.com/6M1Eoy2.png

Fixed: https://i.imgur.com/uLuUgJY.png


Can you post the fixed SVG code, so that I can update my stuff?

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 20:53, ronaldmc wrote:

I don't want to start a war, but this isn't community? I mean aren't we
trying to make things better, because the way you said it seems like a
dictatorship.


It's dictatorship insofar as Walter and Andrei have veto power. If they 
don't want something in, it doesn't go in. I don't think this is a 
problem in practice. If it was, the community could always fork the 
project and then play by their own rules.


And of all things, the logo wouldn't be a good reason to divide over, in 
my opinion.

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 20:08, WebFreak001 wrote:

Original: https://i.imgur.com/6M1Eoy2.png

Fixed: https://i.imgur.com/uLuUgJY.png


:D

Yeah, uhm, that's totally an improvement, of course.

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 16:48, WebFreak001 wrote:

(First I have fixed these weird curves on the D's bottom left and top
left corner.)


What's weird about them? As far as I see, you made the corners more 
pointed, though it's hard to tell at that size. I'm not sure if that's 
an improvement.

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 15:44, WebFreak001 wrote:

However I dont have an SVG for that and I basically just used the logo
from the imgur screenshot, cut of a rounded rectangle (5px border
radius) and added a simple box shadow (0px 1px 3px rgba(0,0,0,0.3))


Here's the SVG. Go crazy.

https://gist.github.com/anonymous/421e80748f1c885f7620

[dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

The logo is repeatedly being called out as a weak spot of the D brand. 
But so far Walter has been adamant about keeping it the way it is.


I agree with him that changing it to a completely different one would 
probably not be a good move, losing whatever brand recognition we have. 
But I think we should adapt the logo to the needs at hand.


It's obvious to me that the D and the moons (the two circles to the 
upper right of the D) make the recognizable core of the logo. I know 
that others see it the same way. That means, the D and the moons should 
be kept intact. Their shapes and positions should not change.


However, I believe we can take away a lot of the decorations of the 
current logo, and it will still be recognized immediately as the same brand.


Here's a little progression of simplifications, in the context of dlang.org:

http://i.imgur.com/eJaKFtx.png

The first one is the current logo. The last one shows just the core 
shape (D + moons), of course.


I'm not nearly the first one to do this, but I'd like to propose 
adopting the core shape as the official logo. Then specify some specific 
shade of red as the official brand color. (We're using #B03931 on 
dlang.org.)


We could provide multiple variants of the logo for different use cases, 
and with varying levels of decoration:


* Core shape in different color combinations (black one white, red on 
white, white on red).
* Versions that include the background arc (I'm interpreting that as 
Mars), possibly in different colors.
* The full version with border and shadow. I.e. the current logo with 
adjusted colors, and maybe some details changed, like number of borders 
or amount of shininess.


For dlang.org, I'd choose the version with the wide background arc. I 
think it looks nice on the menu bar, and it puts a little more emphasis 
there than just the core shape. But just the core shape looks fine, too.

Re: [dlang.org] new forum design

[anonymous via Digitalmars-d]

On 18.01.2016 21:32, wobbles wrote:

On the reddit thread, a bug in safari was posted:
"
I found a bug on Safari 7.1.3: each time I click the "Edit" button for
the code editor, the gray panel with the code it in gets longer, and
pushes the rest of the content in the site down. Here's an album with
the before/after screenshots. http://imgur.com/a/TIylc
"
https://www.reddit.com/r/programming/comments/41j1nm/check_out_ds_new_site/cz32v1v


We may already have a ticket for this:
https://issues.dlang.org/show_bug.cgi?id=15548

I have no idea what's going on here, and I don't have a Mac. So if 
anyone with access to Safari could have a look at this, that would be 
great :)


I've tried using browserstack.com to make sense of this. But you only 
get 30 minutes free trial time, and after 16 minutes all I know is that 
removing `editor.refresh()` from the edit button action [1] seems to 
help. But the "Reset" button still messes things up. Also, since this 
apparently wasn't an issue with the old design, and the JS code hasn't 
been touched, this should be fixable in CSS.



[1] 
https://github.com/D-Programming-Language/dlang.org/blob/818d38b19cfa357e79d991c55fd3a63d7fd9a39f/js/run.js#L492

Re: [dlang.org] new forum design

[anonymous via Digitalmars-d]

On 18.01.2016 20:35, Andrej Mitrovic via Digitalmars-d wrote:

On 1/18/16, anonymous via Digitalmars-d  wrote:

[...]

Microsoft does this.



And techcrunch apparently too..


Another one: stackoverflow

Re: [dlang.org] new forum design

[anonymous via Digitalmars-d]

On 18.01.2016 19:59, Andrej Mitrovic via Digitalmars-d wrote:

Btw, drop-down menus which do not drop-down on hover are really
strange. I've never seen a drop-down menu on a modern website which
required you to click to open and click to close.


Microsoft does this.

Re: Rust's website is really good

[anonymous via Digitalmars-d]

On 16.01.2016 16:53, karabuta wrote:

OK. How do I contribute to the design? I will run away if I have to go
through a long process b4 i can do that:)


In the end someone will have to make a successful pull request against 
the dlang.org git repository. That means cloning the repository, 
applying your changes, and pushing through review. When the changes are 
non-trivial, it means being/getting familiar with Ddoc and the other 
stuff that's used in the dlang.org code.


There's a wiki page about all that:
http://wiki.dlang.org/Contributing_to_dlang.org

You can very meaningfully contribute without doing all that yourself, 
though. An HTML+CSS mockup goes a long way. It can be discussed, 
approved/rejected, and if you're not willing/able to do the actual 
dlang.org code, maybe someone else takes it on. That's exactly how the 
current push for the red-top-bar redesign came about.

Re: [dlang.org] new forum design - preview

[anonymous via Digitalmars-d]

On 16.01.2016 14:18, Jacob Carlborg wrote:

I think it's too small to be useful. I always read in landscape mode
because I think the font size is too small. It would be even better if
the reader view worked (iPhone).


Looks like I had accidentally made it a bit smaller. Fixed it.

Re: [dlang.org] new forum design - preview

[anonymous via Digitalmars-d]

On 13.01.2016 18:13, Saurabh Das wrote:

+1 for Sans-serif fonts! I find them much easier to read too :)
(anonymous has assured me that this font will grow on me though).


I only said it grew on me :)


The page is too white. The style looks good on the main website, but on
the forum makes it difficult to read.


Does that mean it's bad for reading longer text? We shouldn't use white 
background for large parts of the main site either then.

Re: [dlang.org] new forum design - preview

[anonymous via Digitalmars-d]

On 14.01.2016 22:58, ddd wrote:

Cant you do a max-width on the container holding the main page? I agree
it should


I guess there should be a "not" in here?


be an entire 2k display but my laptop the sidebar could easily
push the edge of the window.


The container has a max-width. There's still a padding to the left of 
the subnav so that the grey box is aligned with the D logo above.

Re: [dlang.org] new forum design - preview

[anonymous via Digitalmars-d]

On 14.01.2016 23:03, tsbockman wrote:

On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote:

Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png


Either of those would be an improvement.


I went with the border. It's easier to implement and less likely to be 
controversial. http://beta.forum.dlang.org does not show it yet. I guess 
Vladimir needs to push a button for that.

Re: [dlang.org] new forum design - preview

[anonymous via Digitalmars-d]

On 14.01.2016 16:29, tn wrote:

I don't use my browser in full screen mode, but the useless white
margins are still there. With the horizontal-split mode the line length
of the message is less than 60 characters. Compared to that, I would be
happy with 80 or 90 you suggest.


This is an issue with the horizontal split mode, right? In the other 
modes you should get more than 80 characters on a line.


I agree that horizontal split looks quite cramped right now, unless you 
hide the navigation.



Besides, especially the margin that is on the left side of the
navigation bar looks ugly, like it was rendered improperly.


Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png

Re: local import hijacking

[anonymous via Digitalmars-d]

On 14.01.2016 15:25, Byron Heads wrote:

I got burned by this yesterday, this code should not compile

import std.experimental.logger : trace;


void foo() {
 import std.net.curl : trace;
 trace("hello");
}


void main() {
 foo();
}


I don't see a problem with that specific code. You're explicitly 
importing `trace` from std.net.curl, so it can't be surprising that it's 
called.


But change one little detail and this qualifies as hijacking, I think:


void foo() {
import std.net.curl; /* not mentioning trace */
trace("hello");
}


Imagine that std.net.curl didn't have a `trace` function when the code 
was written. std.experimental.logger.trace would have been called then. 
When a `trace` function is then added to std.net.curl, the code suddenly 
calls a different `trace`, without any warning. Hijacking.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 12.01.2016 08:24, Vladimir Panteleev wrote:
> Nice. Is it responsive?

As responsive as the main site. I just updated the dlang.org submodule 
and fixed what got broken.


I'm mostly done now. Pull request is over here:
https://github.com/CyberShadow/DFeed/pull/51

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 11.01.2016 15:58, Vladimir Panteleev wrote:

Ah, sorry, the build instructions are out of date. That file is created
through the makefile (GNUmakefile).


Alright, after `make` it works.

I've started hacking around, no road blocks so far. Looks like this at 
the moment: http://i.imgur.com/yjuXFBq.png


Is there a way to limit the number of loaded posts? I don't need the 
full archive. But the newest posts would be nice; I think 
/frame-discussions ignores ancient posts.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 11.01.2016 13:54, deadalnix wrote:

No, nothing more needs to be added. Things needs to be removed, not
added. I tested on a 15" screen, not even on a small screen.


As far as I understand, you're saying that Learn is too far down. I'm 
saying we can fix that by moving it up to the first row. That would fix 
the problem, right? I don't see how adding some lines to Learn would be 
problematic then.



:hover is pretty much mandatory. Website need to work without JS.


The site works without JS. Not as smoothly, but it works.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 16:23, anonymous wrote:

https://github.com/D-Programming-Language/dlang.org/pull/1187


That one was pulled prematurely, and then reverted.

Round 2: https://github.com/D-Programming-Language/dlang.org/pull/1190

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 23:24, Vladimir Panteleev wrote:

Once this is merged, would you be OK with working together on updating
the forum to the new design?


I wanted to have a look at DFeed, but all I get with a local clone is 
"Internal Server Error". After investigating a bit, I suspect that there 
should be a web/skel.htt file, but it's not in the repository.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 22:14, deadalnix wrote:

  - Learn barely make the cut on my 15' monitor. That's way too low. If
one doesn't know D, one doesn't care about news, community or whatever.


We can shuffle things around, of course. One alternative:

Learn News
Documentation Community
Packages Contribute

http://i.imgur.com/8mQj0rg.png

This would make Learn the most prominent item.

There is an empty void between Learn and Documentation. It could be 
filled by putting more into Learn. I don't know what to write there, though.


This would sort of split the items in a consumer oriented left column 
and a contributor oriented right column. Which makes me think that I'm 
over-thinking this.



  - Please don't make me click on the menus. You can also make them work
with pure CSS using :hover


I think it was Adam who spoke out against :hover menus, preferring to 
click instead. So we're at 1:1 now, I guess?

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 22:18, Iain Buclaw via Digitalmars-d wrote:

I echo this, and would add a further point that you should have tested all
sub-domains before uploading.  Release archive is not looking well.

http://downloads.dlang.org/


Uhm, where can I fix that? downloads.dlang.org isn't part of the of 
dlang.org repository, is it?

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 23:03, cym13 wrote:

Note that this url shouldn't even exist: the link on the main page for
the download section points to http://dlang.org/download.html . I
believe it is a left-over from a previous version.


downloads.dlang.org is linked from download.html ("Release Archive"). So 
yeah, we dropped the ball on that one.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 19:04, Saurabh Das wrote:

What is the canonical way to report bugs on the website?


Website bugs go into the same bug tracker as compiler and library bugs:

https://issues.dlang.org/

Select "dlang.org" for component.


On mobile, the red "your code here" merges with the code itself.


Yeah, that's not good. I'm not sure what the best fix for this would be. 
Do you have anything in mind?

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 18:02, Saurabh Das wrote:

On the font used, Roboto Slab: I feel that the serif nature of the font
makes it clash with the clean design. A sans serif font would look much
better.


At first I felt so, too, but the font grew on me. I think it works well.


"Your Code Here" widget
-

[...]

I suggest displaying the first 7-9 lines of code in the box and either
making the box scrollable, or making it so that clicking on the box
expands it to show the entire code.


I'd rather just put a hard limit on the length of examples. But 
scrollable/expandable code would be better than a large empty void below 
the download button.



The "Sort lines" example is about the right size. The "Round floating
point numbers" is a bit large.


I agree that "Round floating point numbers" is a tad too long. I think 
it's in an acceptable area, though.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 21:50, mate wrote:

I have one issue with icons display on my laptop, although they display
well on my phone:
http://imgur.com/lZWgWI4
http://imgur.com/KZWBiVr

Usually this kind of issues is due to my use of script blocker, but
disabling it and reloading the page does not seem to fix it.

Any idea?


The icons are done using FontAwesome. Do the icons work on their 
examples page?


https://fortawesome.github.io/Font-Awesome/examples/#basic

Also, what browser are you using, and what operating system?

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 08.01.2016 23:32, anonymous wrote:

My implementation of the redesign is pretty much complete.

Check it out: http://d-ag0aep6g.rhcloud.com/


No blocking issues in sight so far. Time to make a pull request:

https://github.com/D-Programming-Language/dlang.org/pull/1187

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 15:27, Bastiaan Veelo wrote:

Can I ask not to use dotted frames?


I agree that they're ugly, but they've been ugly before the redesign, 
too. Let's do such stuff in separate pull requests.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 11:35, Jacob Carlborg wrote:

I'm not sure that I like that some of the headers (learn, packages) are
clickable on the main page. This also causes some icons to be black
(gray?) and some to be red. How about a link at the end of the section
with the title "Read more", or similar?


Agreed. I unlinked Learn and Packages. The links were duplicated in the 
text already anyway.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 22:43, Andrei Alexandrescu wrote:

On 1/8/16 5:32 PM, anonymous wrote:

[...]

5) Justified Text

[...]

Justified font only looks good in conjunction with hyphenation. I'd say
make text justified on browsers that support css hyphenation (all but
Chrome I recall?) and left align on the others.


I.e., revert the change. Done.

By the way, in Ubuntu I don't see any hyphenation in Firefox. It works 
in Windows, though.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 23:24, Vladimir Panteleev wrote:

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

[...]

Once this is merged, would you be OK with working together on updating
the forum to the new design?


Sure.


3) New Pages

[...]

Perhaps also link to (or even replace with) the wiki pages:

http://wiki.dlang.org/Articles
http://wiki.dlang.org/Development_tools


Added links. About replacing, let's see later.


6) Red For Clickables Only?

[...]

Perhaps just use bold without a color change for symbol highlighting?


That works pretty well with the new de-emphasized template constraints 
and a monospaced font (as per Jack Stouffer's request). So uncolored, 
bold symbols and red borders it is.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 23:36, Jack Stouffer wrote:

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

[...]

4) Fonts

[...]

One nitpick here: can you change the function signatures to use a
monospace font (any will do really)?


Done.


Also, can you institute this change
to the function signatures as well:
https://github.com/D-Programming-Language/dlang.org/pull/1169


It's already in. You have to look at the pre-release docs. The release 
docs are built with an older dmd.


Example: 
http://d-ag0aep6g.rhcloud.com/phobos-prerelease/std_algorithm_searching.html#.commonPrefix



5) Justified Text

[...]

See my arguments here:
https://github.com/D-Programming-Language/dlang.org/pull/1152


I'm going the conservative route for now, keeping the text justified. I 
don't think hyphenation/justification is worth the troubles, but Andrei 
is the one that would have to be convinced here.



6) Red For Clickables Only?

[...]

I would take the converse of your conclusion because I have to disagree
with the use of red for links. People expect links to be blue and
underlined and darker when they are already visited; it's one of the
only design standards that exists on the web.

If you change links to be blue, then you can keep red as a highlight color.


I think that standard is pretty weak, more of a default really.

We want a red site, not a blue one. Links are the site's number one 
source of color. Blue links would make for a blue site with a red bar on 
top.


Re visited links: I removed the :visited styling without thinking too 
much about it, as I don't consider it very important. Am I wrong?

[dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

My implementation of the redesign is pretty much complete.

Check it out: http://d-ag0aep6g.rhcloud.com/

This is an implementation of a design done by one Ivan Smirnov, brought 
forward by Jacob Carlborg [1].


The dark forum widgets on the home page are in iframes. Their styling 
will need to be updated at the source, which is forum.dlang.org.


Another external dependency is the This Week in D script. Adam, it would 
be nice if the `setTwid` function could take the date separately. That 
would allow me to word the text without having "This Week in D" there twice.


Other than those two little things I consider this done. From my side it 
could be merged immediately.


But I'm sure there are a thousand things wrong with this. Here are some 
topics to get you started:


1) Legalities

I mentioned this before, but noone reacted. Can we use Ivan's work? Do 
we have his ok? Do we need it? Jacob mentioned that he can't in contact 
with him anymore. Is that a problem?


2) Reviewing the code

https://github.com/aG0aep6G/dlang.org/commits/Ivan-Smirnov's-redesign

This is just one giant commit (the others are independent minor fixes). 
GitHub refuses to show the diff for the style.css file, because it's too 
big. Is this acceptable, or do I need to split it up somehow? If I need 
to split it up, any advice on how to do that?


3) New Pages

Aside from the overall style changes and menu reorganization, I also 
added overview pages for the articles and for the tools:


http://d-ag0aep6g.rhcloud.com/articles.html
http://d-ag0aep6g.rhcloud.com/tools.html

They feature new text that should be proofread.

4) Fonts

Vladimir Panteleev has spoken out against web fonts [2]. His argument is 
that they can look fine on one system but bad on another. Indeed the 
recently changed code font on dlang.org looks pretty bad for me while 
the default 'monospace' looks just fine, which is why I reverted that in 
the redesign.


The redesign uses a web font for its main font, though: Roboto Slab. It 
looks good for me, but I'm not able to test it on a large variety of 
device/OS/browser combinations. Maybe it's fine, or maybe we should stay 
away from web fonts categorically. I don't really have an opinion on this.


5) Justified Text

Andrei loves it, everybody else hates it. I killed it as the mockup 
didn't have it. Is that ok, or is justified text a must?


6) Red For Clickables Only?

Currently, the site uses red almost exclusively for clickable stuff. But 
it's also used as a highlight color for non-clickable things. For 
example in phobos signatures:


http://d-ag0aep6g.rhcloud.com/phobos/object.html#.Object

The left borders of the signature boxes are red, and the documented 
symbol is highlighted with red.


Red does not signal clickability here. I don't like that and I'd prefer 
to go with another color for generic highlighting, reserving red for 
clickable stuff.


7) The Logo

As requested by Andrei, this does not feature a logo change for now. I'm 
going to make a pull request for the slicker logo variant [3] when this 
is through.



[1] http://forum.dlang.org/post/n53ps0$2j8f$1...@digitalmars.com
[2] http://forum.dlang.org/post/xezfeilxblfkibldv...@forum.dlang.org
[3] https://gist.github.com/aG0aep6G/0803ec5ae49f6afb0196

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 16:36, welkam wrote:

On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

However, my stance at the moment is that the intro examples should
just be really short. The message is that you can do something useful
or cool in just a couple lines of code. That means outright rejection
of anything longer than, say, 20 lines, or maybe even just 15.


Or put longer examples behind "Learn more" button.


Totally. A page with longer, explained examples would be great. We do 
have some longer examples in the "Why D?" section at the bottom, so 
maybe a "see more examples below" link would work for now.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 12:49, Bastiaan Veelo wrote:

On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

Yeah, I also stripped some of its functionality (processing args
instead of stdin),


I sometimes use this box to quickly test something. Although I have
never had a use for args, I might in the future. I found it was nice to
see that it could do that.


I didn't cut the args functionality from the code box, just from that 
one example.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 12:36, Bastiaan Veelo wrote:

Understand. But IMO the main objective should be to demonstrate
expressiveness and productivity to newcomers, and therefore it is
crucial that the examples are understandable in its entirety by every
newbie. Someone unfamiliar to D's UFCS and template instantiation syntax
are likely unable to parse these examples in their heads without
explanatory comments. Without the comments this example reduces to an
incomprehensible blob of code without structure (in the eyes of a
first-time visitor, who may not have a degree in CS) and is likely to
repel instead of attract.


I don't agree that examples need to be fully understandable to newbies. 
We'd have to explain every single line. Rather, I think the examples 
should answer the question "How familiar or outlandish will D be for me?"


That said, I'm not against comments, and I may have gone overboard when 
cutting that example down. But I still think it's too long with all 
comments intact.



This looks pretty frightening if the objective
is just to round floating point numbers (as explained by the only
remaining comment) -- of course we know that this does a lot more, but a
newbie doesn't.


Maybe the example should focus on command line arguments instead of 
stdin. No "replace anything that looks like a number", which is hard to 
match properly anyway, but instead just assume numbers in args. No regex 
necessary, just a `.map!(arg => arg.to!real.round.to!string)`.


Unfortunately, it looks like the handling of command line args is broken 
on dpaste: https://issues.dlang.org/show_bug.cgi?id=15050



A competition for writing the most concise code does not necessarily
produce the most illustrative introductions into a language.


It's not a competition to write the shortest, but a competition to come 
up with something that's short enough. While being short it should 
actually be properly formatted, idiomatic D code.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 16:55, Jacob Carlborg wrote:

I noticed that the buttons for the example cover the drop down menu for
Resources, if it's open.


Fixed, thanks.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 16:33, welkam wrote:

in http://d-ag0aep6g.rhcloud.com/

comunity, learn, documentation and packages are redundant. They either
should be in meniu or not on front page. And if there are redundant
links they should be in footer.


I'm not sure if redundancy is to be avoided here. I think the redesign 
took a lot of inspiration from  which has the same 
preview snippets of the different site sections. Personally I could do 
without them, and I wouldn't mind if we decide against them, but a 
little tour around the site and direct links to the interesting parts 
may help people find what they're looking for.



Now documentation.

anonymous:http://d-ag0aep6g.rhcloud.com/phobos/std_algorithm_iteration.html

Me playing around:
https://drive.google.com/file/d/0B6ofJyypw1tGa29aTGNVQVJQcVk/view?usp=sharing


Open them both and just look at them for 10 sec. Dont scroll because I
put 0 work after License:. Just look at them and write which one has
bigger strain on you eyes.


I'm not sure what you want me to notice. Differences I see:

* different shade of red throughout,
* heading is red,
* no "Jump to" links,
* links are not underlined,
* less horizontal lines on the table.

Regarding the specific shade of red: I don't really care about any exact 
colors. I'm not usually doing visual design, and my monitor is not 
properly calibrated.


Re the red heading: I'm against coloring unclickable stuff the same as 
clickable stuff. I'm guilty of doing this with the signature boxes: the 
red border on the left and the documented symbol are red but not 
clickable. I took that from the mockup, but I don't like it. If the 
point of the red heading is to lessen the contrast, I'd suggest a color 
other than red, maybe just some grey that's less dark than #333.


Re link underlines: I made a pull request for un-underlined links 
before. The argument that made me abandon the idea was that it makes 
things harder for color blind people. Note that already links are not 
underlined in navigation areas where it's supposedly obvious that 
they're clickable.


Re the jump links: I'm not sure if this is a deliberate change of yours, 
or maybe it's just a problem with the JS. If it's deliberate, the 
paragraph below applies.


Re the table lines: I didn't touch those. They're the same in my version 
as on the current dlang.org. Generally, I'd like to leave improvements 
that are independent of the redesign out of it.


If I'm missing anything you'll have to spell it out for me.


IMHO everyone who is working on improving website should get on skype or
hangouts and make a plan. Now Ivan made new design for documentation,
anonymous also put some work, Adam is cooking something up. I smell lots
of redundant work ahead


Aside from general visuals, I'm deliberately leaving Ivan's ideas for 
the phobos docs out for now. Exactly because there's some turmoil in the 
area. And because I want to wrap this up sometime soon. I think Adam's 
work is pretty much independent from mine here.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 07.01.2016 10:02, Bastiaan Veelo wrote:

About the "Your code here" box: I accidentally had your page and
dlang.org side-by-side with the same "Round floating point numbers"
example, only yours had the inline comments stripped.


Yeah, I also stripped some of its functionality (processing args instead 
of stdin), and I dropped the RPN calculator example entirely, because I 
couldn't get it down to acceptable size.



I think the
comments add a lot of value, and would advise to leave them in. I know
this design looks bad when that box gets too high, and I think we would
need a solution that allows examples with more lines without the length
of the example affecting the layout of the page. Here are a few ideas
(without knowing whether they would be doable or not):

   1. Box with fixed height and a slider to scroll the contents.
   2. Manually resizable box, much like the edit field in the online
forums, with a slider when necessary.
   3. Box clipped to a fixed height (possibly with fade-out effect at
the bottom). It could be expanding dynamically on mouse-over. The
buttons would probably be best to have at the top.
   4. The drop-downs in the "Why D?" section work very well. Similarly,
the box could be clipped as in 3 and expand on click. Encourage clicking
on it by having a big "Play" button on it as you see on video's -- or
something similar.


Thanks, the idea of making the example expandable somehow didn't occur 
to me.


However, my stance at the moment is that the intro examples should just 
be really short. The message is that you can do something useful or cool 
in just a couple lines of code. That means outright rejection of 
anything longer than, say, 20 lines, or maybe even just 15.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 06.01.2016 09:00, welkam wrote:

This reminded me when at work we got new design in html/css and had to
put it on the site. It looked better but lacked 1/3 of fields and
functionality. Then backend developers had to fix design and in the end
it was better than before but not as good as html/css from designer.


Also check out http://d-ag0aep6g.rhcloud.com/ where I'm currently 
working on the implementation. It's a little different from the mockup, 
precisely because I'm trying not to drop features/content.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 27.12.2015 15:04, Jacob Carlborg wrote:

https://drive.google.com/open?id=0B7UtafxGD9vEQTVjeXZhSDdRZDA


The caret seems to be a bit high maybe, but otherwise that's how it's 
supposed to look. Feel free to criticize, of course.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 26.12.2015 21:21, Jacob Carlborg wrote:

It does work, but it looks like it affected other bowers as well
(Firefox).


That's weird. Does it look bad?


BTW, I still think that a custom look would be better.
Something like the search field in Firefox. It has a the magnifier icon
which acts like a menu.


I'm hesitating to go that way, because:
a) I don't want to put more on my plate than necessary at this point.
b) It would require Javascript, right? That's not a problem in itself, 
but figuring out a good fallback mechanism seems to be difficult here.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 26.12.2015 13:19, Jacob Carlborg wrote:


No, it's not a cache thing, the new top menu is there. What I mean is
that the Phobos documentation (for example) doesn't use the new design.
Same syntax colors for the syntax highlighting, same green color for the
Phobos docs and so on.


Yeah, I hadn't looked into those, yet. Did so now just now, and updated 
the site. I'm not so sure about coloring the documented symbols the same 
way as links, though. Maybe some nice blue/green/cyan instead of the 
link red?


For now, I'm not going to try to implement the expandable phobos docs or 
the cross references, because they're non-trivial and I think they can 
be done later on. Also, Adam apparently has similar plans for the phobos 
docs. I think I'll wait and see what comes from that, first.



This is how it looks like for me using Safari on OS X [1]. This is
the bug I reported to Bootstrap [2].

[1] https://drive.google.com/open?id=0B7UtafxGD9vEQmFxT0d1T1JiU1E
[2] https://github.com/twbs/bootstrap/issues/7602


Does that mean I just have to add `-webkit-appearance: none;` to the 
select element? Did that just now. Does it work?

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 25.12.2015 12:51, Jacob Carlborg wrote:

Most of the pages do not seem to be updated.


I don't know what you mean. Could this be a cache thing? Can you give a 
specific example, maybe with a screenshot?



The drop down in the search fields looks very bad in Safari on OS X. I
think this is a general problem with bootstrap.


This version doesn't use Bootstrap anymore. I just changed some details 
from the current dlang.org, the core mechanism should work the same.


If the current dlang.org looks ok, but mine doesn't, then I must have 
messed up something. It looks fine for me, though, and I have no OS X 
around to check. Further assistance would be appreciated.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 21.12.2015 14:58, anonymous wrote:

http://d-ag0aep6g.rhcloud.com/

On GitHub if people want to play around with it:
https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

That's a full clone of dlang.org in the new style. I just pasted it over
the old style, and hacked around on top of it until it worked, more or
less. It's a quick and dirty showcase. I touched everything, but
polished nothing. There are more rough edges than smooth ones.


Since Andrei and Jacob are having creative differences, I figured I'd 
just go ahead with this my way, without changes to the tooling.


This is a more proper implementation of the redesign than what I showed 
before:



http://d-ag0aep6g.rhcloud.com/

https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


It's far from done, and I don't know if I'm going to work more on it 
over the holidays. So next year maybe.


Todo/notes:

* Legalities

What's the legal status of this? Did Ivan Smirnov give his permission to 
use the visuals? If not, can we get it, do we need it?


* Reorganization of the menu

I reorganized the menu quite a bit. The layout simply doesn't allow for 
many top level items. I don't think it's for the worse.


* Logo

Using the current D logo for now.

* Medium width menu bar

Try making the browser narrower until the main menu bar has two lines of 
text. I don't like that solution, but switching to the layout with the 
menu button seems silly at that point. Suggestions welcome.


* Subnav on narrow screens

Example: http://d-ag0aep6g.rhcloud.com/spec/intro.html

Can't have it as a side bar when the window is too narrow. Solution 
could be to have a link back to a dedicated TOC page instead. 
Suggestions welcome.


* "your code here" height

Many "your code here" snippets are too long. Cut them down, or change 
the layout to accommodate for them? I'd go with cutting them down. That 
may make the whole "your code here" idea pointless.


* Fonts

Do we go with Roboto Slab? What fallback fonts to use, and in what 
order? Candidates from the current dlang.org and from the mock-up are: 
Helvetica, Verdana, Arial, Deja Vu, BitStream Vera Sans.


I didn't adopt the monospace font from the mock-up, because it looked 
pretty bad to me (rather wide, isn't it?). Plain 'monospace' is DejaVu 
Sans Mono on my system. That one looks better, imo.


* That blank space below "Documentation" on the home page

If anyone has an idea on how to stuff it, shoot.

* Forum and twitter widgets

Does anyone make use of these? I'd totally throw them out, but it may 
better to be conservative for now. Have to style them properly then.


* forum.dlang.org and visuald.dlang.org

... will have to be updated, too. I think this is a good opportunity to 
unify the menu situation.


* "Home" link?

Do we need a named Home link in the menu bar, or is the clickable logo 
enough? There is no other way to get to the home page.


* "your code here" link

Would be nice if the subject line could be prefilled with "[your code 
here]".


* Javascript fallbacks

Simply haven't done those, yet.

* Deletions that would maybe go under the radar

These things were beloved by some (i.e. Andrei), but in the redesign 
they are no more:


  * the Slogan
  The D Programming Language
  Modern convenience. Modeling power. Native efficiency.
  * justified text (can easily make a comeback)
  * the GitHub ribbon in the upper right corner on the download page

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 22.12.2015 16:43, Dmitry wrote:

I agree. My message was that current design supports any size, but new
design does not support widescreens.


There's a point where claiming more horizontal space doesn't improve the 
usability of the site any more.


Yes, more stuff fits on one screen, but readability suffers when text 
lines get too long. And we have lots of short lines on dlang.org, so we 
don't get that much more stuff on the screen anyway. The only thing we 
really achieve is bad looks.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 22.12.2015 16:01, Dmitry wrote:

On Tuesday, 22 December 2015 at 13:38:48 UTC, Charles wrote:

[...]

To be fair, D's documentation uses a left-side menu, but it removes
the top level navigation (you have to press the logo).

Yep, new design has _same_ solution.


No, the mock-up doesn't provide a library menu at all (it glances over 
the issue), and the hacked-together full preview provides a vertical 
library menu in addition to the horizontal main menu. Neither is the 
same as dropping the main menu completely, which is what the current 
dlang.org does.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 21.12.2015 16:45, Adam D. Ruppe wrote:

Let's not underestimate, but let's not overestimate either, I'm pretty
confident these bugs could all be fixed in a day of tweaking, probably
less than that. It looks reasonable right now.


Possibly, but the whole thing still needs to be implemented properly. I 
just added all the CSS from the mock-up on top of the existing stuff. We 
don't want to keep it that way.


Finding all the little issues in the different sections of the site may 
take its time, too. And then there are forum.dlang.org and 
visuald.dlang.org.


Also, things like the overcrowded menu bar, and overly long code 
snippets (on the home page) need decisions, which can take a while if 
people are not in immediate agreement.


On doing it right, I'm not sure how to approach the Bootstrap grid 
thing. Use it with raw HTML/CSS? That may be more complicated than just 
doing things without a framework like that. And switching dlang.org over 
to some preprocessor is not trivial, and may be deemed "too disruptive 
for too little gain".

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 21.12.2015 15:46, Adam D. Ruppe wrote:

Huh, that's mildly buggy but I'm actually pretty impressed with it.


It's definitely very buggy. This is nowhere near releasable quality. I 
put this up so that we have a better preview of the thing. I always feel 
like mock-ups glance over the pain points.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 21.12.2015 15:13, Andrei Alexandrescu wrote:

What are the changes to the tooling used and the build process?


Uh, none? I'm not sure if I understand the question. It's just DDoc, 
CSS, etc, as usual.



Is there a reasonable decay if javascript is disabled?


I guess, we'd set up dedicated pages as alternatives for the drop-down 
menus. They could be copies of the little overview snippets from the 
home page, or just lists of links.



Can we defer any changes to the logo so we don't get sidetracked in
this? Just scale the existing logo to fit and defer any changes to it to
later.


Fine with me.

Does that mean you are principally on board with this, save for details 
like the logo?

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 19.12.2015 15:33, Jacob Carlborg wrote:

http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


I know you wait for Walter's and Andrei's approval on this before 
investing more work. That's very reasonable. Luckily, I'm not so 
reasonable ;)


http://d-ag0aep6g.rhcloud.com/

On GitHub if people want to play around with it:
https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

That's a full clone of dlang.org in the new style. I just pasted it over 
the old style, and hacked around on top of it until it worked, more or 
less. It's a quick and dirty showcase. I touched everything, but 
polished nothing. There are more rough edges than smooth ones.


I changed various details from the mock-up (logo, icons, text, ...), so 
this is not a perfect port. In particular, I tried not to throw out 
content and features from the current dlang.org. For now, that is. The 
home page is pretty crowded, and the menu bar definitely needs to be 
streamlined.


By the way, I'm not sold on that font. I think I'd prefer a sans-serif.

Re: Some feedback on the website.

[anonymous via Digitalmars-d]

On 15.12.2015 22:50, deadalnix wrote:

I get more and more irritated by how non factual the whole IT scene is.
Why does it boils down to opinion ?

A good rule of thumb: if you can't notice and click on the button
immediately while drunk, it is not big and obvious enough.

The proposed design is better that what we have now, but it is still
clumsy. There are box into box, and way too much infos.

It is not opinion, it is what works. If one is of different opinion,
there is an easy way to settle: do an A/B test and settle. I can tell
you, on that one the result that would come out of this are fairly obvious.


What "works" means is still debatable. Is it a goal to get users to the 
download quickly, or are other things equally or more important?


Also, we don't really have the resources to do studies on these things, 
do we? So when you say that it's obviously this way and someone else 
says it's obviously that way, we're back to opinions.


Also, to reiterate, a more noticeable download button is not off the 
table. I pulled back all style changes in that PR to focus on the 
functionality first (which I kinda gave up on by now, too, because it 
turned out to be more difficult than I had hoped).

Re: We need better documentation for functions with ranges and templates

[anonymous via Digitalmars-d]

On 15.12.2015 15:03, rumbu wrote:

There is no indication what happens if the range is undefined in D docs.
In fact, inconsistent behavior:
- it will return 0 in case of null arrays;
- it will throw AccessViolation for null ranges (or probably segfault on
Linux);


I don't think the behavior is inconsistent. A "null array" is rather 
different from a null pointer/reference. If anything is inconsistent, 
I'd say it's the meaning of `null` in the different contexts.


A null pointer may be considered "undefined", but a "null array" is 
certainly not undefined. A "null array" has a null pointer and a length 
of zero. The zero length makes it so that the null pointer won't be 
dereferenced.


Thinking about arrays in terms of null is probably misleading. Instead, 
I'd suggest to think in terms of the empty array []. It's the exact same 
value, but it's more obvious what's going on.

Re: Some feedback on the website.

[anonymous via Digitalmars-d]

On 15.12.2015 08:07, deadalnix wrote:

The navigation can get very confusing. The forum and the site look the
same, but the logo in the top right bring back to the site index/forum
index . That is not what is expected. If it looks the same, it should
probably be doing the same.


Agreed. And the phobos pages have yet another navigation variant that 
looks similar but has different elements.



On the website, the forum is hidden in the community menu in the middle
of the left bar called community. If it warrant its own domain name, it
should probably not be hidden.


The accordion menus have been introduced somewhat recently (early 2015 
IIRC) to make the menu more structured, less crowded. Recently, a number 
of things have been suggested to be put at the top level. The problem 
is, if we put everything at the top level, we end up with an overcrowded 
menu again.


Not saying that the forum shouldn't be at the top. But if we move it up, 
we should probably move something else down.



On the website, categories in the left bar, there are
+ and - sign that looks like button to open/close the category, but they
aren't button. It breaks common expectations.


Not sure what you're asking for here. The +/- signs are part of a button 
that expands/collapses the sub menus. What behavior would you expect/prefer?



There is no way to search the spec.


Is implemented and merged. The site just hasn't been updated yet.

https://github.com/D-Programming-Language/dlang.org/pull/1162


Home page:

[...]

Our is just messed up. The download link is there, but just doesn't
stand out (same presentation as this week in D, videos from DConf, as
big as the changelog).


I agree, others don't. See discussion on 
 where I 
originally proposed this download button: 
.


Now, I don't want to complain about people not liking the design. And I 
pulled the design changes back rather quickly, because the functionality 
was supposed to be the subject of the PR. A big, flashy download button 
has not exactly been rejected.

Re: We need better documentation for functions with ranges and templates

[anonymous via Digitalmars-d]

On 14.12.2015 23:31, bachmeier wrote:

I don't want to debate this. If it's the official position that Phobos
documentation is written for experienced users of the language, then so
be it. I'll have to tell others to use a practical language.


Relax, Jack Stouffer is not the spokesman for D or phobos. He doesn't 
express official positions. (Not implying that you tried to give the 
impression, Jack.)


As far as I see, people generally agree with you that the current way of 
displaying the signatures is too cryptic. What to do exactly about it is 
open for debate, of course. And then someone actually has to do the 
work, of course.

Re: Rust's simple download script

[anonymous via Digitalmars-d]

On 10.11.2015 14:12, Márcio Martins wrote:

Could then combine this with OS detection through user-agent on the
website and show the user the most likely option and command-line
suggestion.


Relevant PR that detects the OS and adds a direct download link to the 
right file to the homepage:

https://github.com/D-Programming-Language/dlang.org/pull/1139


Another thing I would do is not show LDC and GDC in the front page but
have a "other options" sort of thing. People are afraid to fail and each
decision is a potential failure that will scare new people off. The idea
is that people that already use D know where to find the other compilers
and more importantly what they are, but someone that does not use D
might get intimidated by too many choices they don't have the knowledge
to make confidently.


Exactly.

Re: assert(0)

[anonymous via Digitalmars-d]

On 07.11.2015 22:00, Fyodor Ustinov wrote:

We do not have way to in "scope(failure)" or "scope(exit)" detect - it's
"assert" or "throw".


Ah, I get what you mean now. I think you have a point. Executing 
scope(failure/exit) code when an Error has been thrown may be bad. I'm 
not aware of the details, though.

Re: assert(0)

[anonymous via Digitalmars-d]

On 07.11.2015 21:38, Fyodor Ustinov wrote:

1. I should generally _not_, but I _can_.


D lets you to shoot your own foot, yes. You're encouraged not to do it, 
though.



2. Without "-release" assert(0) launches scope(exit), scope(failure) and
"finally" blocks. I.e. we get a completely different behavior in
"-release" and not "-release" mode.


Yeah, -release drastically changes how asserts behave. That's its 
purpose. A program should not fail asserts. If it does, that's a bug. In 
particular, assert(0) should never be reached. If it is reached, that's 
a bug.

Re: assert(0)

[anonymous via Digitalmars-d]

On 07.11.2015 19:42, Fyodor Ustinov wrote:

Well. assert(0) located in very-very dangerous place. If we suddenly got
to this place - Program should die immediately, otherwise there will be
something terrible.

But without "-release" this place less dangerous? Why without "-release"
this assert behaves like any other (throw exception and we can cath it,
for example)?


Asserts throw Errors, not Exceptions. You should generally not catch 
Errors. That's just as dangerous without -release as with it.

Re: DIP 84: Static Inheritance

[anonymous via Digitalmars-d]

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
From the discussion here: 
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwd...@forum.dlang.org).


So the only other way is a DIP (http://wiki.dlang.org/DIP84) 
for language and compiler support for static inheritance. It's 
backwards-compatible and IMHO worth looking at.


Please let me know what you think.

Atila


To be honest. The idea of having a library fix error messages 
seems sort of like a band-aid solution rather than a real 
solution. Don't get me wrong, I use band aids, but I think the 
DIP solution is a more proper approach. As far as the DIP, I like 
what was proposed.


Structs can't currently inherit and so wouldn't need static. 
However, it might be preferable to require it anyway for parity 
with classes:


I would say I agree that it should be required, just for 
consistency sake.

Re: #ifdef hell

[anonymous via Digitalmars-d]

On Thursday, 29 October 2015 at 23:10:38 UTC, Walter Bright wrote:

On 10/29/2015 3:23 PM, rsw0x wrote:
On Thursday, 29 October 2015 at 22:18:11 UTC, Walter Bright 
wrote:

https://www.cqse.eu/en/blog/living-in-the-ifdef-hell/

Another voice on what is wrong with the snarl of #ifdef's.


how does this differ from static if and version(x) hell?


We advise people not to use static if to do what version(x) 
eschews, and suggest better alternatives.


The same thing can be said about #ifdef. Conventional wisdom in 
C++ says there's better ways, but the abuse compiles thus 
continually abused.

Re: Playing SIMD

[anonymous via Digitalmars-d]

On 25.10.2015 20:37, Iakh wrote:

Full exaple with comparation of algorithms (SIMD, naive, binary search):
http://dpaste.dzfl.pl/f3b8989841e3


From there:

void runBinary()
{
static int i = 0;
naiveIndexOf(cast(ubyte)(i++/ArraySize + 1), arr);
}


runBinary calls naiveIndexOf. You're not testing binaryIndexOf.

Re: "tuple unpacking" with zip?

[anonymous via Digitalmars-d]

On Wednesday, October 21, 2015 06:21 PM, Shriramana Sharma wrote:

> Dear me... I meant UTF-8 encoded byte, rather than "codepoint",

Also known as: code unit.

Re: s/TypeTuple/AliasSeq/g?

[anonymous via Digitalmars-d]

On Wednesday, October 21, 2015 06:49 AM, Shriramana Sharma wrote:

> BTW "isExpressions" – what kind of singular/plural grammar is that? When
> renaming `isExpressionsTuple`, I would think it more appropriate to have
> "isExpressionSeq" since it's an `AliasSeq` containing only expressions and
> no types.

Makes sense to me. However, the similar name "isExpressionTuple" has 
apparently been dropped in favor of "isExpressions" in the past. Maybe dig 
up the discussion on that.

> Also, though `AliasSeq` is the same as `TypeTuple`, it would seem
> `isTypeTuple` is not the same as what an `isAliasSeq` would be, since
> `isTypeTuple` seems to test for an `AliasSeq` containing only types and no
> expressions. Possibly this inconsistency is one of the reasons for the
> name change?

Yup.

> Anyhow, given that we are removing all references to "tuple", I would
> think "isTypeSeq" would be the appropriate parallel renaming of
> `isTypeTuple` to "isExpressionSeq".

If "isExpressionSeq" gets through, yes. If "isExpressions" stays, then 
"isTypes"? :/

> But should there then be a separate `isAliasSeq`? I'm not sure how to do
> that. Code is appreciated...

I don't think an isAliasSeq template makes sense. Every set of template 
arguments is an AliasSeq, so isAliasSeq would just always return true. 
There's no point in that.

Re: 0 in version number?

[anonymous via Digitalmars-d]

On Sunday, October 18, 2015 05:09 AM, Shriramana Sharma wrote:

> By `ls -v1` I was illustrating that directory listing utilities are
> capable of sorting numbers meaningfully, so there is no need for leading
> zeroes for *that* purpose...

You only showed that ls can do it, and you need a special flag for it. 
That's not very conclusive.

Re: D 2015/2016 Vision?

[anonymous via Digitalmars-d]

On Monday 05 October 2015 21:07, Meta wrote:

> There's a critical flaw in `scoped`. Observe:
> 
> import std.stdio;
> import std.typecons;
> 
> class A
> {
>   string name;
> 
>   this(string name)
>   {
>   this.name = name;
>   writeln("Creating A");
>   }
> 
>   ~this()
>   {
>   writeln("Destroying A");
>   }
> 
>   void hello()
>   {
>   writeln("Hello, ", this.name);
>   }
> }
> 
> void main()
> {
>   auto a1 = scoped!A("Foo");
>   a1.hello();
> 
>   A a2 = scoped!A("Foo");
>   a2.hello();
> }
> 
> 
> The output:
> 
> Creating A
> Hello, Foo
> Creating A
> Destroying A
> Destroying A
> object.Error: Access Violation

You're getting at the segfault, right? The example can then be much simpler:


import std.typecons;

class A
{
void hello() {}
}

void main()
{
A a2 = scoped!A();
a2.hello(); /* segfault */
}

Re: Idioms you use

[anonymous via Digitalmars-d]

On Tuesday 29 September 2015 15:06, Cauterite wrote:

> some statements

Buf of course! I totally didn't think of multiple statements. Thanks.

Re: Idioms you use

[anonymous via Digitalmars-d]

On Monday 28 September 2015 23:40, Freddy wrote:

> Are any D idioms you use that you like to share?
> Heres one of mine
> ---
> enum ctfe =
> {
>  return 0xdead & 0xbad;
> }();
> ---

Why not just `enum ctfe = 0xdead & 0xbad;`?

Are there cases where `enum foo = {return bar;}();` works but `enum foo = 
bar;` doesn't? And if there are, aren't they compiler bugs?

Re: Moving back to .NET

[anonymous via Digitalmars-d]

On Sunday 20 September 2015 19:39, Andrei Alexandrescu wrote:

> Off the top of your head, can you list a few of the worst error messages 
> you've encountered?

Not Adam, but this is on the top of my head as it just happened:

http://stackoverflow.com/questions/32681660/compiler-thinks-enum-values-are-starting-at-129

Re: Floating point in the type system

[anonymous via Digitalmars-d]

On Saturday 12 September 2015 18:08, Robert wrote:

> It's unusual, because `float.nan != float.nan`, so one might 
> expect that `typeof(Foo!(float.nan) != Foo!(float.nan))`, whereas 
> this is clearly not the case, even with both the static assert 
> and runtime assert failing. I'm just curious to understand the 
> reasoning behind this, whether it's intentional, and whether it 
> matters at all.

I don't know what the compiler actually does, but it looks like the 
comparison of template value arguments doesn't use equality, but something 
more akin to `is` instead (bitwise equality).

If that's right, then `is(Foo!(float.nan) == Foo!(float.nan))` holds because 
`float.nan is float.nan` holds.

Same behavior with a struct instead of float:

struct S
{
bool opEquals(S other) {return false;}
}
struct Foo(S s)
{
}
static assert(S.init != S.init); /* not equal */
static assert(S.init is S.init); /* but bit for bit identical */
static assert(is(Foo!(S.init) == Foo!(S.init)));

Re: Better lambdas!!!!!!!!!!

[anonymous via Digitalmars-d]

On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
Of course, this hides the names outside the lambda, but a 
warning could be issued(no different than if one does it 
explicitly.


This makes the parameter names part of the API. The author of a 
library is unable to rename parameter without breaking user code. 
I do not believe the benefit is large enough to accept such a 
drawback.