[Issue 17231] Function to get name from Tid

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17231

--- Comment #6 from Vladimir Panteleev  ---
(In reply to RazvanN from comment #5)
> I made a PR for that issue and since you closed your PR for this one, I
> thought that marking this one as a duplicate would make more sense.

You may want to wait until your PR is merged before closing the respective
issue. If your PR ends up being closed for whatever reason, then the
"duplicate" issue will likely remain incorrectly closed.

--

Re: Auto-decoding

[ag0aep6g via Digitalmars-d-learn]

On 07/15/2017 06:21 AM, bauss wrote:
I understand what it is and how it works, but I don't understand 
anything of how it solves any problems?


Could someone give an example of when auto-decoding actually is useful 
in contrast to not using it?


1) Drop two elements from "Bär". With auto-decoding you get "r", which 
is nice. Without auto-decoding you get [0xA4, 'r'] where 0xA4 is the 
second half of the encoding of 'ä'. You have to know your Unicode to 
understand what is going on there.


2) Search for 'ä' (one wchar/dchar) in the `string` "Bär". With 
auto-decoding, you pop the 'B' and then there's your 'ä'. Without 
auto-decoding, you can't find 'ä', because "Bär" doesn't have a single 
element that matches 'ä'. You have to search for "ä" (two `char`s) instead.


The goal of auto-decoding was to make it so that you don't have to think 
about Unicode all the time when processing strings. Instead you could 
think in terms of "characters". But auto-decoding falls flat on that 
goal, which is why it's disliked. You still have to think about Unicode 
stuff for correctness (combining characters, graphemes), and now you 
also have to worry about the performance of auto-decoding.

[Issue 17643] std.traits.getSymbolsByUDA doesn't work with private attributes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17643

Vladimir Panteleev  changed:

   What|Removed |Added

   Severity|normal  |regression

--- Comment #4 from Vladimir Panteleev  ---
- Started working with https://github.com/dlang/phobos/pull/3827, which allowed
getSymbolsByUDA to work on private members
- https://github.com/dlang/dmd/pull/5530 caused accessing the field result in a
deprecation, but it still worked (and returned both members)
- https://github.com/dlang/phobos/pull/5344 has broken this completely.

This certainly seems like a regression, but I'm not sure I can put the blame
entirely on either of those PRs.

--

Re: sorting a string

[ag0aep6g via Digitalmars-d-learn]

On 07/15/2017 04:33 AM, Namal wrote:

Why does it have to be char[]?

  auto bytes = line.representation.dup;
  bytes.sort;
  string result = bytes.assumeUTF;

works too.


That's a compiler bug. The code should not compile, because now you can 
mutate `result`'s elements through `bytes`. But `result`'s elements are 
supposed to be immutable.


I've filed an issue: https://issues.dlang.org/show_bug.cgi?id=17654

[Issue 17650] [REG v2.075.0 b1-b4] std.getopt range violation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17650

--- Comment #4 from Vladimir Panteleev  ---
Actually, I believe we do count a breakage as a regression if something breaks
for the end-user, regardless of what is going on under the hood. E.g. it's
possible that for supported architectures, the range violation was completely
benign.

--

[Issue 17651] Segfult when parsing Ddoc ESCAPES macro

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17651

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 17654] New: return value incorrectly considered unique when casting to another pointer type

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17654

  Issue ID: 17654
   Summary: return value incorrectly considered unique when
casting to another pointer type
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Found by Namal in D.learn:
http://forum.dlang.org/post/eqoejftfcptbiclyb...@forum.dlang.org

Original code:

void main()
{
import std.algorithm;
import std.string;
char[] line;
auto bytes = line.representation.dup;
bytes.sort;
string result = bytes.assumeUTF; /* should be rejected */
}


Reduced to show it's a compiler bug:

char[] assumeUTF(ubyte[] str) pure { return cast(char[]) str; }

void main()
{
ubyte[] b = ['a', 'b', 'c'];
string s = assumeUTF(b); /* should be rejected */
assert(s == "abc"); /* passes */
b[0] = '!';
assert(s == "abc"); /* fails */
}


Another variant to show it's not about arrays or the char type:

ubyte* toBytePointer(uint* p) pure { return cast(ubyte*) p; }

void main()
{
uint* i = new uint;
immutable ubyte* b = toBytePointer(i); /* should be rejected */
*i = 0xFF_FF_FF_FF;
assert(*b != 0xFF); /* fails */
}


--

[Issue 17650] [REG v2.075.0 b1-b4] std.getopt range violation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17650

--- Comment #3 from Vladimir Panteleev  ---
Interesting - looking at the PR, this doesn't really seem like a regression,
rather that the addition of the @safe attribute exposed an out-of-bounds array
access that was always there. Feel free to reclassify, Jon.

--

[Issue 17650] [REG v2.075.0 b1-b4] std.getopt range violation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17650

--- Comment #2 from Vladimir Panteleev  ---
Introduced in https://github.com/dlang/phobos/pull/5351

--

[Issue 17648] dmd segfault on overload set introspection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17648

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||ice

--

Re: Exported Class Error

[rikki cattermole via Digitalmars-d-learn]

On 15/07/2017 5:31 AM, Damien Gibson wrote:

Hi. I find myself comming back here alot which is a little discouraging.

This time around, I have a dll im making, right now its 32bit using dmd 
cause i have been getting better information when compile errors occur.


if i have a class in it, and i call export on all the functions i want 
exposed and attempt to use this class in an application that calls 
either a static or shared lib it fails to compile giving me an error:


  Error 42: Symbol Undefined _D4asfw7network6server6server7__ClassZ
obj\Debug\serverApp.obj(serverApp)
  Error 42: Symbol Undefined 
_D4asfw7network6server6server6__ctorMFkZC4asfw7network6server6server

obj\Debug\serverApp.obj(serverApp)
  Error 42: Symbol Undefined _D4asfw7network6server12__ModuleInfoZ
Error: linker exited with status 3
Exit code 3

I had compiled in LDC2 compiler and this particular error was extended a 
little more to tell me that all 3 of these errors are caused on the 
exact same line where i declare a class object i named socket (outside 
of said function so its global) --


'socket = new Server(my param data);'

My main assumption was much less that the first and third error reports 
meant anything significant in this case but moreso because it wasnt 
finding the constructor which seems to me to point at the __ctor one. 
However when i open the shared library with depends.exe the exact 
'_D4asfw7network6server6server6__ctorMFkZC4asfw7network6server6server' 
exists in the dll, just without the _ at the beginning so im thinking 
maybe something about the .di file is making it think there should be a 
_ at the beginning and maybe some way i can modify the di will make it 
stop adding this because that function IS there.


Also i am not sure if this is a related issue, but i have another dll 
which the above mentioned problem dll and app cant find some structures 
i made unless i specificly compile it as a static library and the 
structure does happen to be used IN the constructor of the server object 
that keeps failing.


Any help would be appreciated ive been trying to figure out what the 
heck to do with this for about 2 days now and not getting an inch further.


TypeInfo doesn't cross the dll boundary atm on Windows.
Known bug.

Which means no classes or exceptions.

https://issues.dlang.org/show_bug.cgi?id=4071

[Issue 14982] nogc inconsistency

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14982

--- Comment #3 from Vladimir Panteleev  ---
Just to confirm, by "fixed" you mean that all three now consistently fail to
compile?

FWIW, the change seems to have been accidental: the second and third function
compiled before and don't compile after https://github.com/dlang/dmd/pull/5271.

--

[Issue 17646] dmd segfaults on missing foreach body in import

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17646

--- Comment #3 from Vladimir Panteleev  ---
FWIW, no segfault before https://github.com/dlang/dmd/pull/708.

--

[Issue 17645] `pure` is transitively applied to all delegates inside a pure function

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17645

--- Comment #2 from Vladimir Panteleev  ---
FWIW, the test case works in DMD 2.013 through 2.027 :)

--

Exported Class Error

[Damien Gibson via Digitalmars-d-learn]

Hi. I find myself comming back here alot which is a little 
discouraging.


This time around, I have a dll im making, right now its 32bit 
using dmd cause i have been getting better information when 
compile errors occur.


if i have a class in it, and i call export on all the functions i 
want exposed and attempt to use this class in an application that 
calls either a static or shared lib it fails to compile giving me 
an error:


 Error 42: Symbol Undefined _D4asfw7network6server6server7__ClassZ
obj\Debug\serverApp.obj(serverApp)
 Error 42: Symbol Undefined 
_D4asfw7network6server6server6__ctorMFkZC4asfw7network6server6server

obj\Debug\serverApp.obj(serverApp)
 Error 42: Symbol Undefined _D4asfw7network6server12__ModuleInfoZ
Error: linker exited with status 3
Exit code 3

I had compiled in LDC2 compiler and this particular error was 
extended a little more to tell me that all 3 of these errors are 
caused on the exact same line where i declare a class object i 
named socket (outside of said function so its global) --


'socket = new Server(my param data);'

My main assumption was much less that the first and third error 
reports meant anything significant in this case but moreso 
because it wasnt finding the constructor which seems to me to 
point at the __ctor one. However when i open the shared library 
with depends.exe the exact 
'_D4asfw7network6server6server6__ctorMFkZC4asfw7network6server6server' exists in the dll, just without the _ at the beginning so im thinking maybe something about the .di file is making it think there should be a _ at the beginning and maybe some way i can modify the di will make it stop adding this because that function IS there.


Also i am not sure if this is a related issue, but i have another 
dll which the above mentioned problem dll and app cant find some 
structures i made unless i specificly compile it as a static 
library and the structure does happen to be used IN the 
constructor of the server object that keeps failing.


Any help would be appreciated ive been trying to figure out what 
the heck to do with this for about 2 days now and not getting an 
inch further.

Re: Toward Go 2 (or D needs to collect experience reports)

[Matt via Digitalmars-d]

The one thing I got from that blog post is that the HN and reddit 
discussion was overwhelmingly about generics, and how the Go 
leadership seems to not give a damn about what its user community 
wants...

Auto-decoding

[bauss via Digitalmars-d-learn]

I understand what it is and how it works, but I don't understand 
anything of how it solves any problems?


Could someone give an example of when auto-decoding actually is 
useful in contrast to not using it?


Just trying to get an understanding of what exactly its purpose 
is.


I did read 
https://jackstouffer.com/blog/d_auto_decoding_and_you.html


But I still feel like there's not a clear explanation of what 
issues exist when you don't have it.


If I need to be more clear, just let me know.

[Issue 17622] [REG2.075.0-b1] Wrong code with appender and -inline

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17622

--- Comment #6 from Vladimir Panteleev  ---
Reduced:

 test.d ///
struct S
{
int i;

this(ubyte)
{
return;
}

void fun()
{
assert(i == 0);
}
}

S make()
{
return S(0);
}

void main()
{
S s = make();

auto rdg =
{
s.fun();
};

s.fun();
}
///

--

Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)

[rikki cattermole via Digitalmars-d-announce]

On 14/07/2017 7:10 PM, Martin Tschierschke wrote:

On Friday, 14 July 2017 at 15:21:09 UTC, rikki cattermole wrote:
[...]

Scale your dreams back a bit.

If you want to put money into anything here is my list:

1. Get shared libraries 100% working, with clear articles on how to 
use it, on every platform.

2. std.experimental.color, it seems Manu is stalled
3. std.experimental.image, ok ok, this one is mine but its about time 
we get the damn interfaces standardized in Phobos!
4. GUI widget rendering library, GUI widget != GUI toolkit (think just 
rendering a single control), basically handles rendering + accessibility.


These are not big projects, but they would go a long way to getting 
any thing really "cool".
Keep in mind, money talks. Getting the right people available to work 
on a project full time for a few months would really speed a lot of 
this stuff up.


There is also other stuff like a bidi library, font rasterizer and 
other more useful infrastructure projects that actually has a chance 
of being completed.


Depending on how far you want to go, my list alone is a few years 
worth of work for a 3-5 people team.


What about the following idea:
We extend DUB (the website) with a direct link for a paypal donation for 
every package. If a certain minimum amount is in, the D Foundation 
organizes the funding of the ongoing development?


Regards mt.


That is a service, which D Foundation shouldn't be offering.

Anyway, they don't have enough money to do that.
Somebody needs to come in and foot the bill, otherwise this type of 
infrastructure code is all on peoples own time and desire.

[Issue 17622] [REG2.075.0-b1] Wrong code with appender and -inline

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17622

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|inline  for m64 fails web   |[REG2.075.0-b1] Wrong code
   |APPS|with appender and -inline
   Severity|major   |regression

--- Comment #5 from Vladimir Panteleev  ---
This is a regression.

Introduced in https://github.com/dlang/dmd/pull/6852

Partial reduction:

 test.d 
void main()
{
import std.array : appender;

auto content = appender!(ubyte[])();

auto rdg = ()
{
auto x = content.data;
};

content.put(new ubyte[912]);
}


--

[Issue 17622] inline for m64 fails web APPS

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17622

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords|dll |wrong-code
   Hardware|x86 |All
 OS|Windows |All

--- Comment #4 from Vladimir Panteleev  ---
(In reply to steven kladitis from comment #3)
>  the above fails in -m32 or -m64 when using -inline

Thanks, reprocuded. Reducing.

--

[Issue 12963] posix.mak hardcodes $(CC) as cc on non Windows system

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12963

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Jason King from comment #0)
> This has the effect of hardcoding $CC to cc on non-Win32 systems.

Wait, how so? Can't you just specify CC=... on the make command line to
override it?

(In reply to RazvanN from comment #1)
> If another compiler needs to be used, a different branch can be easily
> added. Closing as invalid

I agree that this should probably be closed by now , as it was filed 3 years
ago and seems like a non-issue with a trivial workaround, but not with your
close reason, as enhancements in makefiles are just as valid enhancement
requests as in the compiler or standard library.

--

Toward Go 2 (or D needs to collect experience reports)

[Seb via Digitalmars-d]

Very interesting article: https://blog.golang.org/toward-go2

The highlights:

Our goal for Go 2 is to fix the most significant ways Go fails 
to scale.


Go 2 must bring along all those developers. We must ask them to 
unlearn old habits and learn new ones only when the reward is 
great.


Go 2 must also bring along all the existing Go 1 source code. 
We must not split the Go ecosystem. Mixed programs, in which 
packages written in Go 2 import packages written in Go 1 and 
vice versa, must work effortlessly during a transition period 
of multiple years. We'll have to figure out exactly how to do 
that; automated tooling like go fix will certainly play a part.


Today, what we need most is experience reports. Please tell us 
how Go is working for you, and more importantly not working for 
you. Write a blog post, include real examples, concrete detail, 
and real experience. And link it on our wiki page. That's how 
we'll start talking about what we, the Go community, might want 
to change about Go.


I believe that if we ever want to see D3, we should start a 
similar process and collect real world feedback about things that 
are annoying on a daily basis.
There have been many threads about "I want to have feature X" in 
D and of course legendary threads like the one about removing 
auto-decoding, but the aim of this discussion is to identify 
things that bother you frequently or prevent you from using D on 
a wider scale.
Please see Russ's post for good examples. Blog posts or reports 
on the wiki are very welcome.

[Issue 12867] std.traits.fullyQualifiedName fails on ClassName.staticMember.memberOfStruct

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12867

Vladimir Panteleev  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |DUPLICATE

--- Comment #2 from Vladimir Panteleev  ---
Before  to 2.057  : Failure
  Fixed   by: https://github.com/dlang/phobos/pull/384 - Add PackageName,
ModuleName and FullyQualifiedName traits.
2.058   to 2.060  : Success with output: fooMember
  Broken  by: https://github.com/dlang/phobos/pull/913 -
`std.traits.hasElaborateCopyConstructor` fixes and other
   2.061  : Failure
  Fixed   by: https://github.com/dlang/phobos/pull/1967 - Issue 10502 - Can't
get fullyQualifiedName of a templated struct
Since  2.066.0: Success with output: test.Foo.fooMember

*** This issue has been marked as a duplicate of issue 10502 ***

--

[Issue 10502] Can't get fullyQualifiedName of a templated struct

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10502

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||donny.viszn...@gmail.com

--- Comment #6 from Vladimir Panteleev  ---
*** Issue 12867 has been marked as a duplicate of this issue. ***

--

[Issue 17639] Implicit conversion of bool to float should be rejected

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17639

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|RESOLVED|REOPENED
  Component|phobos  |dmd
   Hardware|x86_64  |All
 Resolution|INVALID |---
Summary|std.math.approxEqual|Implicit conversion of bool
   |accepts return of isNaN |to float should be rejected
   |(bool) as argument  |
 OS|Linux   |All

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Simen Kjaeraas from comment #1)
> This bug report basically boils down to this code:
> 
> float f = false;

That doesn't make sense and doesn't seem useful, so let's reopen it as an
accepts-invalid.

--

Re: sorting a string

[Namal via Digitalmars-d-learn]

On Friday, 14 July 2017 at 17:23:41 UTC, Steven Schveighoffer 
wrote:



import std.string: representation, assumeUTF;
import std.algorithm: sort;

auto bytes = line.representation.dup;
bytes.sort;
auto result = bytes.assumeUTF; // result is now char[]



Why does it have to be char[]?

 auto bytes = line.representation.dup;
 bytes.sort;
 string result = bytes.assumeUTF;

works too.

[Issue 17541] Function attribute deduction depends on compile invocation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17541

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6995

--

Re: Documentation licence

[Seb via Digitalmars-d]

On Friday, 30 June 2017 at 10:10:14 UTC, ANtlord wrote:
Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service.


Hi,

Did you manage to make progress on this issue? As mentioned this 
is in my focus as well and I will be able to allocate some time 
to help.


Btw @ others there is an open Trello card at the devdocs.io board 
which allows voting:


https://trello.com/c/bCgqhZ4s/123-d

Re: WTF is going on! Corrupt value that is never assigned

[Moritz Maxeiner via Digitalmars-d-learn]

On Thursday, 13 July 2017 at 23:30:39 UTC, Moritz Maxeiner wrote:
Okay, I'll setup a Windows VM when I have time and check it out 
(unless someone solves it beforehand).


I have been unable to reproduce your reported behaviour with dmd 
2.074.1 (same as Adam).

Re: [OT] .net is getting slices

[via Digitalmars-d]

On Friday, 14 July 2017 at 12:50:56 UTC, Kagamin wrote:
On Friday, 14 July 2017 at 12:25:47 UTC, Petar Kirov 
[ZombineDev] wrote:
core.atomic supports 2 * (void*).sizeof atomicLoad, 
atomicStore and cas (compare-and-swap) on platforms that 
support it (x86 and x86_64 for sure, and for others you have 
to check what libatomic (GCC) and llvm do).


If it's not cross-platform, that's a problem.


In theory yes, in practice probably not. Are you worried that 
your code needs to run on platforms where bytes are 9-bit wide? 
What's more, not all CPUs support atomic loads and stores of 8 
bytes, so .NET's Interlocked API that takes System.Double 
arguments is not cross-platform either.
I personally prefer D's approach where you can check at 
compile-time for has64BitCAS on 32-bit targets and has128BitCAS 
on 64-bit ones and write your algorithms accordingly. 
Design-by-Introspection FTW.

Re: Function attribute deduction depends on compile invocation

[Walter Bright via Digitalmars-d]

On 7/14/2017 9:53 AM, Johan Engelen wrote:
What happens in that in one kind of compilation, @nogc is deduced for a 
function. But in another compilation, it isn't. Thus references to the function 
will have the wrong mangling, and linker errors happen:

https://issues.dlang.org/show_bug.cgi?id=17541


At the moment you can work around it by explicitly adding the annotation.

Re: Request for a more powerful template specialization feature

[data pulverizer via Digitalmars-d]

On Friday, 14 July 2017 at 23:04:48 UTC, Stefan Koch wrote:
One important characteristic about constraints, is that they 
are not bound to types.

Also they can from conjunctions and disjunctions.
Combined with ctfe they are very flexible and powerful.

I do not know how you would do the same with specializations.
Then again being unfamiliar with template-specializations I 
might be overlooking something.


True ... it doesn't have to be specializations or constraints, as 
you have said constraints are important for conjunctions and 
disjunctions. I should not have said "why are constraints better 
than specializations". However when you are dealing with a know 
finite set of know types or constructs - which I do frequently, 
it is useful to be able to be able to specify the exact behaviour 
for individuals and different groups clearly and succinctly. For 
instance when writing mathematical algorithms that should apply 
differently to different constructs, its much easier to say "do 
this for that specific construct" and "do something else for some 
group" and so on without having to repeat negating cases.


A practical case might be dealing with two library "kinds" each 
having around 8 possible type specifications where some 
associated methods are related. Sometimes methods will be the 
same for combinations of types both within each kind and across 
both kind combinations. Specializations that allow multiple 
values are really good for these cases.


I currently  use string mixins to code-gen my template 
specializations - its a good-enough but visually inelegant 
solution.

Re: Exception handling

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 14 July 2017 at 23:09:23 UTC, Stefan Koch wrote:

On Friday, 14 July 2017 at 23:02:24 UTC, Moritz Maxeiner wrote:
On Friday, 14 July 2017 at 21:20:29 UTC, Jonathan M Davis 
wrote:
Basically, the  compiler _never_ looks at the bodies of other 
functions when determining which attributes apply. It always 
[...].


I'm well aware of that, but it doesn't mean that it can't be 
enhanced to do so (i.e. what it can do, not what it does do).


"Enhancing" the compiler to do so comes at a very very high 
cost.


That depends on if, how, and when the compiler frontend currently 
does other (unrelated to exceptions) semantic analysis of 
function bodies.


Which would force the compiler to look at every body it can 
look at to maybe discover a closed set of execptions. This 
would kill fast compile-times!


Again, this depends on the exact internals available at the 
semantic analysis time, but in theory, it should be possible that 
when a ThrowStatement is encountered, the surrounding scope 
aggregates the exception's type in it's aggregated exception set 
(ignoring things not inherited from Exception).

I don't think this would necessarily kill fast compile times.

Re: Exception handling

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

On Fri, Jul 14, 2017 at 11:09:23PM +, Stefan Koch via Digitalmars-d-learn 
wrote:
> On Friday, 14 July 2017 at 23:02:24 UTC, Moritz Maxeiner wrote:
> > On Friday, 14 July 2017 at 21:20:29 UTC, Jonathan M Davis wrote:
> > > Basically, the  compiler _never_ looks at the bodies of other
> > > functions when determining which attributes apply. It always
> > > [...].
> > 
> > I'm well aware of that, but it doesn't mean that it can't be
> > enhanced to do so (i.e. what it can do, not what it does do).
> 
> "Enhancing" the compiler to do so comes at a very very high cost.
> Which would force the compiler to look at every body it can look at to
> maybe discover a closed set of execptions. This would kill fast
> compile-times!

The compiler could internally keep track of which exceptions are thrown
by a function when it does a semantic pass on the function body. This
doesn't need to be represented in the language itself.

Also, when the function body is available and the compiler is compiling
code that calls this function, we're going to need to run semantic on
that function anyway, so it doesn't hurt to run semantic right then to
extract the list of exceptions. Later on semantic will just be no-op for
functions that have already gotten semantic triggered by exception
scanning. If that function already has semantic run, then the exception
list is already available so you just read it.

This won't slow the compiler down -- you're still doing the same work,
just in a different order.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, 
binary trees... and bugs.

Re: D easily overlooked?

[aberba via Digitalmars-d]

On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote:

https://blog.sourced.tech/post/language_migrations/



I know people will jump onboard and start yelling how D has 
very unique features but from the "outside world" its always 
the same response. While more people are downloading D and 
trying it out, i barely see any independent D language blogs.


Maybe you havent't looked enough. I blog about D (basic stuff) at 
http://aberba.com/#blog. I wrote one for Opensource.com at 
https://opensource.com/article/17/5/d-open-source-software-development which received some positive feedback. There are other blog posts about D too.


Not to be a downer but D really in my eyes is missing that 
"unique" feature that people care about, that allows people to 
blog about the language...
We care about the existing features done right that D has. In my 
experience, people like D (syntax, features, CTFE, UFCS, modules, 
etc.)... the only thing missing is that "we have more language 
than [real world usage]" coined from what Andre said at DConf.


D is way better and addictive than how I found it in 2014. The 
language and ecosystem keeps getting richer. I can't enjoy coding 
in any other language than I do in D.

Re: Compilation times and idiomatic D code

[Seb via Digitalmars-d]

On Friday, 14 July 2017 at 22:45:44 UTC, H. S. Teoh wrote:

Result: 8MB executable size (!).

Of course, this comes at a runtime cost of an added level of 
indirection (now you have to call a virtual function through 
the interface to integrate with earlier components in the 
pipeline).  But at a 60% reduction in executable size, I think 
it's a worthwhile tradeoff.  :-)


That's a very interesting idea!
However, I wouldn't want to insert this into code manually, maybe 
a simple flag-opt-in support in DMD that detects UFCS pipes with 
X components and then inserts the type erasure hack could solve 
most problems for the time being? That way it wouldn't create a 
WTF moment when explaining D code and when Stefan or someone else 
manages to implement something more sophisticated, no code would 
need an update.

Re: Compilation times and idiomatic D code

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 14, 2017 at 03:45:44PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Here's a further update to the saga of combating ridiculously large
> symbol sizes.
[...]
>.wrapWithInterface // <--- type erasure happens here
[...]

Some further thoughts about type erasure and UFCS chains.

Nobody says type erasure *requires* OO -- that's just an artifact of the
way things are currently implemented.  Consider, for example, your
generic UFCS chain:

auto r = source
.ufcsFunc1
.ufcsFunc2
.ufcsFunc3
...
.ufcsFuncn;

>From the POV of outside code, *nobody cares* what the specific types of
each stage of the UFCS pipeline are.  Only the code that implements
ufcsFunc1, ufcsFunc2, etc., need to know.  Furthermore, suppose X is the
specific type of the range that's returned by ufcsFunc3, in the middle
of the pipeline.  What are the chances this exact type is going to be
reused again later?  Very slim.  And if ufcsFunc2, say, takes an alias
parameter that's instantiated with a lambda function, you can basically
guarantee that this type X will *never* ever be repeated again, outside
of this specific UFCS chain.

And at the end of the chain, typeof(r) really only needs to encode the
fact that it implements the API returned by ufcsFuncn, e.g., the range
methods, element type, etc.. But nobody will care how these API
functions are implemented under the hood -- as far as outside code is
concerned, typeof(r) might as well be an opaque serial number, and we'll
be able to find the instantiated API functions that implement the
methods of r.  IOW, the explicit types of all intermediate stages of the
UFCS chain are irrelevant to the outside world.  Since they are template
functions (most of the time) anyway, the compiler might as well just
glue all their code together, and put it inside functions named like
funcName0012345XYZ where the 0012345XYZ is some random unique string,
basically a serial number, that identifies it as a method of r.

For that matter, typeof(r) might as well be ufcsChain0012345XYZ, since
nobody outside the pipeline itself will care what its component types
are.

So basically, the compiler could just automatically type-erase the type
of such chains, given that (1) none of the UFCS functions "escape"
knowledge about an intermediate type to the outside world, (2) the chain
is essentially unique to the current function (esp. if one or more
components of the chain has an alias parameter bound to a lambda
argument), (3) most UFCS functions return opaque types anyway -- very
few (i.e., almost none) Phobos algorithms, for example, allow you to
recover the type of the previous component of the chain -- so it's not
relevant what the specific types of the previous components are, and (4)
therefore the outside world couldn't care less about the specific types
that compose typeof(r).  It could be as simple as bumping a global
counter and suffixing it to some compiler-reserved prefix, to make type
names like __ufcsType_0123.  This will be far shorter than any
symbol compression applied to present-day symbols!

To summarize, here's a scheme for handling template expansion in UFCS
chains that will produce extremely short symbols, *independently* of how
long your UFCS chains are.  If the compiler sees a UFCS chain with these
characteristics:

1) There are ≥ n components, for some arbitrary value of n (say n=5 or
n=10, or something like that, so that we don't bother with trivial cases
where the full type may actually be important);

2) Each component of the chain is a template function (this one is
almost a given);

3) At least one component guarantees a unique instantiation, e.g., an
alias parameter bound to a lambda function;

then the compiler will:

a) Generate a unique serial number (package.module + global counter
should be good enough);

b) Assign a unique typename to the final return value, constructed using
this serial number;

c) Essentially inline all template bodies of previous stages of the
pipeline into the last one, using the same serial number to generate
names for the aggregated symbols of the final stage.

This way, those ridiculously huge symbols aren't even generated to begin
with, thereby alleviating the need for convoluted compression schemes.


T

-- 
I am not young enough to know everything. -- Oscar Wilde

Re: Exception handling

[Stefan Koch via Digitalmars-d-learn]

On Friday, 14 July 2017 at 23:02:24 UTC, Moritz Maxeiner wrote:

On Friday, 14 July 2017 at 21:20:29 UTC, Jonathan M Davis wrote:
Basically, the  compiler _never_ looks at the bodies of other 
functions when determining which attributes apply. It always 
[...].


I'm well aware of that, but it doesn't mean that it can't be 
enhanced to do so (i.e. what it can do, not what it does do).


"Enhancing" the compiler to do so comes at a very very high cost.
Which would force the compiler to look at every body it can look 
at to maybe discover a closed set of execptions. This would kill 
fast compile-times!

Re: Request for a more powerful template specialization feature

[Stefan Koch via Digitalmars-d]

On Friday, 14 July 2017 at 22:49:18 UTC, data pulverizer wrote:

On Friday, 14 July 2017 at 22:25:15 UTC, data pulverizer wrote:
I am aware that this suggestion touches the language and the 
compiler - and may significant implications. I would like to 
know whether this could be done without too much effort and 
whether it would break anything else?


If you are writing lots of overloaded templates, constraints 
can have unintended behaviour because you end up telling the 
compiler what not to do rather than what to do. The above 
Unions are clear and simple, easy to use and should result in 
cleaner more robust code.


In addition with template specializations you get constraints 
for free. If I implement template overloads which are all 
specializations, the compiler gives me a very informative error 
if I step outside the pre-defined set of implementations. 
That's just brilliant - exactly what you want! I immediately 
know when I see that error what the issue is. Am I being naive? 
Why are constraints better?


One important characteristic about constraints, is that they are 
not bound to types.

Also they can from conjunctions and disjunctions.
Combined with ctfe they are very flexible and powerful.

I do not know how you would do the same with specializations.
Then again being unfamiliar with template-specializations I might 
be overlooking something.

Re: Compilation times and idiomatic D code

[Stefan Koch via Digitalmars-d]

On Friday, 14 July 2017 at 22:45:44 UTC, H. S. Teoh wrote:
On Thu, Jul 13, 2017 at 03:27:31PM -0700, H. S. Teoh via 
Digitalmars-d wrote:

[...]

[...]

Here's a further update to the saga of combating ridiculously 
large symbol sizes.


[...]


You will be excited to hear that my template work will fix the 
described problem as a side effect.
Without incurring run-time overhead. Or forcing the usage of OO 
wrappers.
The downside however is that the scheme I have in mind is very 
complex and might take over a year to implement.

Re: Exception handling

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 14 July 2017 at 21:20:29 UTC, Jonathan M Davis wrote:
On Friday, July 14, 2017 9:06:52 PM MDT Moritz Maxeiner via 
Digitalmars-d- learn wrote:

On Friday, 14 July 2017 at 20:22:21 UTC, Ali Çehreli wrote:
> Although it's obvious to us that there are only those two 
> exceptions, the compiler cannot in general know that.


Not in general, no, but if the function's body (and the body 
of all functions it calls) are available, the compiler can 
aggregate the exception set and indeed perform a more precise 
nothrow analysis.


Except that that's not how it actually works, and it would 
probably violate the language spec if it did.


That the compiler currently does not do so is not relevant to the 
fact that it can do so, if implemented - AFAICT it wouldn't 
violate the spec.


Basically, the  compiler _never_ looks at the bodies of other 
functions when determining which attributes apply. It always 
[...].


I'm well aware of that, but it doesn't mean that it can't be 
enhanced to do so (i.e. what it can do, not what it does do).


For it to work otherwise would actually cause a lot of problems 
with .di files.


The compiler would simply skip declarations without bodies, i.e. 
things for them would be exactly as they are now; that's 
precisely why I wrote that all bodies of called functions must be 
available for it to work. If one is missing, it just collapsed to 
what we have today (unless we introduced optional exception set 
declaring in function signatures, which is controversial).

Re: Compilation times and idiomatic D code

[H. S. Teoh via Digitalmars-d]

On Thu, Jul 13, 2017 at 03:27:31PM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jul 13, 2017 at 04:16:50PM -0400, Steven Schveighoffer via 
> Digitalmars-d wrote:
> [...]
> > http://www.schveiguy.com/blog/2016/05/have-your-voldemort-types-and-keep-your-disk-space-too/
> [...]
> 
> Whoa.  I just tried your 'horcrux' trick, and discovered that it
> causes a further reduction in executable size!
> 
> Original sizes:
>   38144296 bytes (38.1 MB)
>   61412056 bytes (61.4 MB)
> 
> After factoring out Voldemort structs as module-global private structs:
> 
>8332352 bytes (8.3 MB)
>   10376584 bytes (10.4 MB)
> 
> After further refactoring to use the "horcrux" trick:
>8147392 bytes (8.1 MB)
>   10124136 bytes (10.1 MB)
[...]

Here's a further update to the saga of combating ridiculously large
symbol sizes.

So yesterday I wrote a new module that also heavily uses UFCS chains.
My initial draft of the module, once I linked it with the main program,
particularly with a UFCS chain that has led to the 600MB executable
sizes seen above, caused another explosion in symbol size that actually
managed to reach 100MB in *one* symbol, triggering a DMD termination
complaining about possible infinite template recursion. :-D  Funnier
still, temporarily simplifying part of the chain to bring symbol sizes
down, I eventually got it below 100MB but ended up with linker segfaults
and ELF errors because the huge symbol was too ridiculously huge.

Eventually, it drove me to refactor two Phobos functions that are used
heavily in my code: std.range.chunks and std.algorithm.joiner, using the
same "horcrux" technique (see Phobos PRs #5610 and #5611). This,
together with some further refactoring in my own code, eventually
brought things down to the 20MB range of executable sizes.

Then an idea occurred to me: the reason these symbol sizes got so large,
was because the UFCS chain preserves *all* type information about every
component type used to build the final type. So, by necessity, the type
name has to somehow encode all of this information in an unambiguous
way.  Now, arguably, DMD's current mangling scheme is at fault because
it contains too many repeating components, but even if you disregard
that, the fact remains that if you have 50+ components in your overall
UFCS chain, the symbol length cannot be less than 50*n where n is the
average length of a single component's type name, plus some necessary
overhead to account for the mangling scheme syntax. Let's say n is on
average 20-25 characters, say round it up to 35 for mangling syntax, so
you're still looking at upwards of 1700+ characters *minimum*.  That,
coupled with the current O(n^2) / O(n^3) mangling scheme, you easily
reach megabytes of symbol length.  We can compress the symbols all we
want, but there's a limit as to how much compression will help. At the
end of the day, you still have to represent those 50+ components
*somehow*.

But what if most of this type information is actually *unnecessary*?  To
use a range example, if all you care about at the end of the chain is
that it's a forward range of ubyte, then why even bother with multi-MB
symbols encoding type information that's never actually used?  Maybe a
little type-erasure would help, via hiding those 50+ component types
behind an opaque runtime OO polymorphic interface.  Phobos does have the
facilities of this, in the form of the InputRange, ForwardRange, etc.,
interfaces in std.range.interfaces.  In my case, however, part of the
chain uses another generic type (a kind of generalization of 2D arrays).
But either way, the idea is simple: at the end of the UFCS chain, wrap
it in a class object that inherits from a generic interface that encodes
only the primitives of the 2D array concept, and the element type. The
class object itself, of course, still must retain knowledge of the
full-fledged type, but the trick is that if we insert this type erasure
in the middle of the chain, then later components don't have to encode
the type names of earlier components anymore.

So, tl;dr:

// Before:
auto r = input
 .ufcsFunc1
 .ufcsFunc2
 .map!(e => e.ufcsFunc3.ufcsFunc4 ...)
 ...
 .ufcsFuncn
 .flattenToRange
 .rangeFunc1
 .rangeFunc2
 ...;

Result: 20MB executable size (600MB before the "horcrux" technique was
applied).

// After:
input.ufcsFunc1
 .ufcsFunc2
 .map!(e => e.ufcsFunc3.ufcsFunc4 ...)
 ...
 .ufcsFuncn
 .wrapWithInterface // <--- type erasure happens here
 .flattenToRange
 .rangeFunc1
 .rangeFunc2
 ...;

Result: 8MB executable size (!).

Of course, this comes at a runtime cost of an added level of indirection
(now you have to call a virtual function through the interface to
integrate with earlier components in the pipeline).  But at a 

Re: Request for a more powerful template specialization feature

[data pulverizer via Digitalmars-d]

On Friday, 14 July 2017 at 22:25:15 UTC, data pulverizer wrote:
I am aware that this suggestion touches the language and the 
compiler - and may significant implications. I would like to 
know whether this could be done without too much effort and 
whether it would break anything else?


If you are writing lots of overloaded templates, constraints 
can have unintended behaviour because you end up telling the 
compiler what not to do rather than what to do. The above 
Unions are clear and simple, easy to use and should result in 
cleaner more robust code.


In addition with template specializations you get constraints for 
free. If I implement template overloads which are all 
specializations, the compiler gives me a very informative error 
if I step outside the pre-defined set of implementations. That's 
just brilliant - exactly what you want! I immediately know when I 
see that error what the issue is. Am I being naive? Why are 
constraints better?

Re: Request for a more powerful template specialization feature

[data pulverizer via Digitalmars-d]

On Friday, 14 July 2017 at 18:19:03 UTC, data pulverizer wrote:

Dear all,

Template specializations are a great feature in D. They allow 
the programmer to create template specializations but they can 
also be a powerful way of constraining templates by 
implementing only the specializations that you need. In 
contrast template constraints can quickly become very complex 
for the programmer to write and reason about.


Template specializations should be extended to allow multiple 
lists of types to be implemented together. For example this ...


template Construct(R: Union{double, int}, W: Union{string, 
char, dchar})

{
auto Construct(R, W)(R r, W w)
{

}
}

The same definition would be allowed for all 6 combinations of 
{double, int} and {string, char, dchar} (and no more! Unless 
specified otherwise and/or more generally). This would remove 
the need to manually write these for all combinations or resort 
to constraints.


In addition for some use cases it is a nicer way of doing 
unions than using the current union keyword. Union{double, int} 
could be a compile-time construct indicating that the type can 
be either an actual double or int. It can replace the use of 
union in cases where you want a substitution of either double 
or int for this Union rather than a union type. In addition, 
variants return variants rather than "properly" typed data.


It would be good to get comments and suggestions before I write 
a DIP.


Thank you in advance.


I am aware that this suggestion touches the language and the 
compiler - and may significant implications. I would like to know 
whether this could be done without too much effort and whether it 
would break anything else?


If you are writing lots of overloaded templates, constraints can 
have unintended behaviour because you end up telling the compiler 
what not to do rather than what to do. The above Unions are clear 
and simple, easy to use and should result in cleaner more robust 
code.

Re: DIP 1011--extern(delegate)--Preliminary Review Round 1

[Jonathan Marler via Digitalmars-d]

On Friday, 14 July 2017 at 17:02:37 UTC, Dmitry Olshansky wrote:
...The dance with making an ABI wrapper can be left to compiler 
proper.


This proposal doesn't make ABI wrappers, it changes the ABI of 
the function itself.

Re: Munich D Meetup July 2017

[Dragos Carp via Digitalmars-d-announce]

Bump the thread, the next Munich D Meetup is getting closer.

Dragos


On Monday, 3 July 2017 at 18:23:27 UTC, Dragos Carp wrote:

Hi all,

On 18 July, we will have our next Munich meetup. Mario will 
give a talk with the title "Avoiding the Big Ball of Mud".
As usual before and after the talk we will also have good 
conversations with pizza and drinks.


Please RSVP on: 
https://www.meetup.com/de-DE/Munich-D-Programmers/events/241264180/


Thanks,
Dragos

[Issue 17194] [scope] Fwd reference error with nested struct

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17194

Elie Morisse  changed:

   What|Removed |Added

 CC||syniu...@gmail.com
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from Elie Morisse  ---
It's not specific to nested classes:

struct S {
S2 a;
}

struct S2 {
void foo(scope S s) { }
}

=> Error: struct S no size because of forward reference

Kinda related: issue 17548 was another bogus forward ref error originating from
the same TypeStruct.hasPointers call in TypeFuntion.semantic (but as I
understand it that call isn't the actual problem).

--

Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)

[aberba via Digitalmars-d-announce]

On Thursday, 13 July 2017 at 05:18:40 UTC, wigy wrote:

On Wednesday, 12 July 2017 at 20:11:06 UTC, Vitor Rozsas wrote:

So... suggestions... Centralized? Decentralized?

I think the centralized wouldn't fit in any country. It would 
certainly contain pedophile posts... and any sane country 
would shut down the servers immediately...


So... DEcentralized?


Hi! I do not think the debate you have with yourself is 
decentralized vs centralized. You are thinking about moderated 
vs unmoderated. One is a technical structure, the other is a 
social one.


We got used to have moderated channels in media and unmoderated 
channels in person. Now the problem we are facing is that we 
use these social media platforms for replacing "in person" 
communications with friend and family. And the owners of these 
platforms are still treating it as "media" that they should 
moderate.


But this is not so black-and-white still. When i am talking to 
my mother-in-law who has different political biases than me, I 
moderate *myself* not to bring up topics that would just divide 
us, because I love her enough to tolerate her opinions. What 
happens is that we have many social circles in which we have 
different topics and ethical norms. This is in our nature and 
that is fine. Football fans ventilate their emotions at the 
game, but they would not use the same language in their 
workplace.


So what I see is that a social media platform should be 
decentralized to avoid influence from its owner. It should be 
divided into many communities. And each community should be 
able to downvote content that is not tolerated in those 
circles. And downvoted content should be also available by 
others, it should just take more actions to peek into that and 
convince yourself that it was indeed something inapt for that 
community.


In the digital world, everything seems to be black and white. 
But social behaviors are more subtle than that. It is easy to 
create a total dictatorial system like facebook, and it is also 
easy to create a total anarchist system like Silk Road. And our 
goal is to create a system that is similar to in-real-life 
communication, which is neither completely free, nor completely 
controlled.


You cannot build that system on top of a centralized 
architecture where a government can just ask for all data 
including a order to keep that secret. People never trusted 
their inner thoughts or family conversation onto the 
government. And they should not.


This answer is brilliant...it comes out of understanding...deep 
thinking


Now...personally I don't think this social media platform 
potential hype will last. Very soon it will get out of hand. It 
means Facebook, etc. that doesn't offer any quantifiable needed 
value will die if they don't innovate out of the social media 
realm. Presure from governments and users needs will facilitate 
the death of the social media market.


But one thing is certain. Security is becoming a problem. Monies 
are becoming digital. There is a rising need for securing digital 
value without sacrificing convenience.


Our systems today are not designed for that. Sooner or later 
those patches we are making to our systems temporary will get 
exhusted.


Its either an innovative use of blockchain-like systems or a 
secure-from-scratch sandboxing system.


Blockchain seem interesting for D.

Re: Exception handling

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, July 14, 2017 9:06:52 PM MDT Moritz Maxeiner via Digitalmars-d-
learn wrote:
> On Friday, 14 July 2017 at 20:22:21 UTC, Ali Çehreli wrote:
> > Although it's obvious to us that there are only those two
> > exceptions, the compiler cannot in general know that.
>
> Not in general, no, but if the function's body (and the body of
> all functions it calls) are available, the compiler can aggregate
> the exception set and indeed perform a more precise nothrow
> analysis.

Except that that's not how it actually works, and it would probably violate
the language spec if it did. Basically, the compiler _never_ looks at the
bodies of other functions when determining which attributes apply. It always
uses the signatures. Even if attribute inferrence it involved, the
function's attributes (and therefore signature) are determined before any
function that's calling it is examined to determine whether it's violating
nothrow or @nogc or whatnot (or whether it can be nothrow or @nogc or
whatnot if its attributes are being inferred). For it to work otherwise
would actually cause a lot of problems with .di files.

- Jonathan M Davis

Re: Exception handling

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 14 July 2017 at 20:22:21 UTC, Ali Çehreli wrote:

On 07/14/2017 12:36 PM, ANtlord wrote:
> Hello! I've tried to use nothrow keyword and I couldn't get a
state of
> function satisfied the keyword. I have one more method that
can throw an
> exception; it is called inside nothrow method. Every type of
an
> exception from the throwable method is handled by the nothow
method.
>
> ubyte throwable_fn(ubyte state) {
> if(state < 2) {
> return 1;
> } else if(state == 3) {
> throw new MyException1("qwe");
> } else {
> throw new MyException2("asd");
> }
> }

Although it's obvious to us that there are only those two 
exceptions, the compiler cannot in general know that.


Not in general, no, but if the function's body (and the body of 
all functions it calls) are available, the compiler can aggregate 
the exception set and indeed perform a more precise nothrow 
analysis.

Re: Request for a more powerful template specialization feature

[Jonathan M Davis via Digitalmars-d]

On Friday, July 14, 2017 4:45:10 PM MDT Andrei Alexandrescu via Digitalmars-
d wrote:
> On 07/14/2017 04:29 PM, Jonathan M Davis via Digitalmars-d wrote:
> > I'd guess that you'd use staticIndexOf an check for
> > -1 to implement it
>
> Given that constraints are user-facing, having a forwarding one-liner
> may be justifiable. -- Andrei

Possibly. It's hard to know sometimes when a one line wrapper is a big
enough boost to usability to standardize. I could see this being such a
case.

staticIndexOf is a bit unwieldy, and I've rarely used it, but when I have,
I think that I've always used it to check whether somehing is present rather
than getting an actual index.

Another tough example would be takeWhile/dropWhile. We already of until and
find, which do the same things respectively but with the opposite predicate
such that they're arguably too simple to be worth adding, but at the same
time, if you have to negate your predicates often enough, having takeWhile
and dropWhile would be a definite boon (also, for many folks, takeWhile and
dropWhile are obvious in a way that until or find might not be - especially
until). Timon was complaining bitterly the other day about the lack of
takeWhile:

https://issues.dlang.org/show_bug.cgi?id=4535

IIRC, I tried to add those several years ago, but you vetoed them on the
grounds that simply negating the predicate was trvial, which is certainly
true, albeit less user-friendly. I don't know what the correct answer is
though. Sometimes, it's clear that adding a one-liner is a pointless
wrapper, whereas in other cases, it seems like a definite usabiliy
improvement.

- Jonathan M Davis

Re: How to get value of type at CT given only an alias

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 14 July 2017 at 18:06:49 UTC, Steven Schveighoffer 
wrote:


.init is the default value.

I'm not sure you can get the default value of a non-default 
initializer, My attempts using init didn't work. e.g.:


void foo(alias T)()
{
   pragma(msg, T.init);
}

struct S
{
   int y = 5;
   void bar() { foo!y; } // prints 0
}


See spec [1]:

"If applied to a variable or field, it is the default initializer 
for that variable or field's type."


If you want to get at the 5 in a static context, you'd have to use

---
S.init.y
---

i.e. get the default initializer for the struct and get its y 
member's value.


[1] https://dlang.org/spec/property.html#init

Re: sorting a string

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, July 14, 2017 7:50:17 PM MDT Anton Fediushin via Digitalmars-d-
learn wrote:
> On Friday, 14 July 2017 at 17:23:41 UTC, Steven Schveighoffer
>
> wrote:
> > Don't do this, because it's not what you think. It's not
> > actually calling std.algorithm.sort, but the builtin array sort
> > property. This will be going away soon.
>
> This sucks. I know, that `.sort` will be removed, but I thought
> it won't break any code.
>
> > With 2.075, it won't compile even without the parentheses,
> > because a char[] is not an array according to std.algorithm...
>
> But why? This should be true for `char[]`, isn't it?
> -
> if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range
>
> || hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
>
> hasAssignableElements!Range) && isRandomAccessRange!Range &&
> hasSlicing!Range && hasLength!Range)
> -
> (It's from
> https://dlang.org/phobos/std_algorithm_sorting.html#sort)

It has to do with Unicode and Andrei's attempt to make ranges Unicode
correct without having to think about it. It was a nice thought, but it
really doesn't work, and it causes a number of annoying problems. As a quick
explanation, in Unicode, you have code units, which combine to make code
points. In UTF-8, a code unit is 8 bits. In UTF-16, it's 16 bits, and in
UTF-32, it's 32 bits. char is a UTF-8 code unit. wchar is a UTF-16 code
unit, and dchar is a UTF-32 cod unit. 32 bits is enough to represent any
code point, so a valid dchar is not only a code unit, it's guaranteed to be
a code point. So, indexing or slicing a dstring will not cut into the middle
of any code points. However, because UTF-8 and UTF-16 potentially require
multiple code units in order to represent a code point, you can't just
arbitrarily index a string or wstring (or arbitrarily slice either of them)
or you risk breaking up a code point.

To avoid this problem and guarantee Unicode correctness, Andrei made it so
that the range API does not treat strings or wstrings as either random
access or sliceable. So, isRandomAccessRange!string and hasSlicing!string
are false. And front returns dchar for all string types, because it decodes
the first code point from the code units, which means that popFront could
pop one char or wchar off, or it could pop several. Similarly, because the
number of code points can't be known without iterating them,
hasLength!string is false.

This does prevent you from blindly doing things to your strings using the
range API which will make them have invalid code points, but it also makes
it really annoying for stuff like sort, because sort requires a random
access range to sort, but char[] and wchar[] are not considered to be random
access ranges, because they're considered to be ranges of dchar rather than
char or wchar. It also hurts performance, because many algorithms don't
actually need to decode the code points - which is why many Phobos functions
have special overloads for strings; they do the decinding only when required
or skip it entirely.

To make matters worse, not only is all of this frustrating to deal with, but
it's not even fully correct. When Andrei added the range API to Phobos, he
thought that code points where the character you see on the screen (and
annoyingly, Unicode _does_ call them characters for some stupid reason), but
they really aren't. They do represent printable items, but they don't just
include characters such as A. They also include stuff like accents or
subscripts such that you sometimd actually need multiple code points to
represent an actual character on the screen - and a group of code points
which represent a character or glyph that you'd see on the screen are called
grapheme clusters. So, to be fully correct, ranges would have to decode
clear to grapheme clusters by default, which would horribly inefficient. The
correct way to handle Unicode requires that the programmer understand it
well enough to know when they should be operating at the code unit level,
when they should be operating at the code point level, and when they should
be operating at the grapheme level. You really can't automate it -
especially not if you want to be efficent. And you rarely want the code
point level, making Andrei's choice particularly bad.

So really, ranges should not be treating strings in a special manner; they
should be treated as ranges of code units and require the programmer to wrap
them in ranges of code points or graphemes as appropriate. But
unfortunately, making that change now would break a lot of code. So, we seem
to be stuck. The result is that you're forced to either specialize your
functions on strings or use functions like std.string.representation or
std.utf.byCodeUnit to work around the problem. And of course, this whole
issue is incredibly confusing to anyone coming to D - especially those who
aren't well-versed in Unicode. :(

- Jonathan M Davis

Re: Request for a more powerful template specialization feature

[Andrei Alexandrescu via Digitalmars-d]

On 07/14/2017 04:29 PM, Jonathan M Davis via Digitalmars-d wrote:

I'd guess that you'd use staticIndexOf an check for
-1 to implement it


Given that constraints are user-facing, having a forwarding one-liner 
may be justifiable. -- Andrei

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/14/2017 03:06 PM, Lurker wrote:

On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote:

Example 1: Polymorphism

class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) { 
assert(0); }  };

class EvolvedPenguin : Penguin { override void fly() { ... } };



No matter how you look at it, this code should simply not be allowed:

Bird bird = ...;
bird.fly(); // is this return or noreturn?

Penguin penguin = ...;
penguin.fly(); // is this return or noreturn?

In both cases, compiler cannot draw any conclusions about 
return/noreturn and thus I believe such code should not be allowed.


Conventional thinking has it that derived methods should "require less 
and deliver more" such that substitution is possible. That's where 
contravariant parameters and covariant returns come from. Therefore, 
methods that do not return should be able to override those that return. 
(The opposite is unworkable btw.) Note that the absence of a "noreturn" 
annotation does not imply a guarantee that the method does return.


Andrei

Re: sorting a string

[ag0aep6g via Digitalmars-d-learn]

On 07/14/2017 09:50 PM, Anton Fediushin wrote:

But why? This should be true for `char[]`, isn't it?
-
if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || 
hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
hasAssignableElements!Range) && isRandomAccessRange!Range && 
hasSlicing!Range && hasLength!Range)

-


No, those are all false. char[] is treated as a range of code points 
(dchar), not code units (char). It's decoded on-the-fly ("auto decoding").


Code unit sequences are variable in length. So to get the n-th code 
point you have to decode everything before it. That's too expensive to 
be considered random access.


Same for swappable/assignable elements: When the new sequence has a 
different length than the old one, you have to move everything that 
follows to make room or to close the gap. Too expensive to be accepted 
by the templates.


As for why auto-decoding is a thing:

The idea was to treat char[] and friends as ranges of visual characters 
to have a robust default where you don't accidentally mess your strings 
up. Unfortunately, a code point isn't always what's commonly understood 
as a  character (grapheme), and the whole things falls apart. It's a 
historical accident, really.


Here's a huge discussion thread about maybe getting rid of it:

http://forum.dlang.org/post/nh2o9i$hr0$1...@digitalmars.com

And here's what I took away from that:

http://forum.dlang.org/post/nirpdo$167i$1...@digitalmars.com

[Issue 17653] New: Redefining symbol in separate but identical template namespaces is completely ignored

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17653

  Issue ID: 17653
   Summary: Redefining symbol in separate but identical template
namespaces is completely ignored
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

Not sure whether to mark this rejects-valid or diagnostic.

template foo(T) {
   struct R { int x; }
   auto foo(T t) { return R(1); }
}

template foo(T) {
   struct R { string s; }
   auto foo(T t, bool f) { return R("hi"); }
}

void main()
{
   foo(1);
   foo(1, true);
}

Error: cannot implicitly convert expression ("hi") of type string to int

It appears that the second foo is using the first foo's R to return. However,
if I defined R twice in the same template it would complain. It appears that
the second R is just simply ignored. That shouldn't happen.

--

Re: sorting a string

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/14/17 3:50 PM, Anton Fediushin wrote:

On Friday, 14 July 2017 at 17:23:41 UTC, Steven Schveighoffer wrote:
Don't do this, because it's not what you think. It's not actually 
calling std.algorithm.sort, but the builtin array sort property. This 
will be going away soon.


This sucks. I know, that `.sort` will be removed, but I thought it won't 
break any code.


With 2.075, it won't compile even without the parentheses, because a 
char[] is not an array according to std.algorithm...


But why? This should be true for `char[]`, isn't it?
-
if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || 
hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
hasAssignableElements!Range) && isRandomAccessRange!Range && 
hasSlicing!Range && hasLength!Range)

-
(It's from https://dlang.org/phobos/std_algorithm_sorting.html#sort)


static assert(!isRandomAccessRange!(char[]));
static assert(!hasSlicing!(char[]));
static assert(!hasAssignableElements!(char[]));
static assert(!hasSwappableElements!(char[]));
static assert(!hasLength!(char[]));

It's because of autodecoding :) Phobos does not view char[] as an array, 
but rather a range of decoded dchar elements. It causes no end of problems.


-Steve

Re: Request for a more powerful template specialization feature

[Jonathan M Davis via Digitalmars-d]

On Friday, July 14, 2017 3:49:05 PM MDT Andrei Alexandrescu via Digitalmars-
d wrote:
> On 7/14/17 2:19 PM, data pulverizer wrote:
> > template Construct(R: Union{double, int}, W: Union{string, char, dchar})
>
> template Construct(R, W)
> if ((is(R == double) || is(R == int))
>  && (is(W == string) || is(W == char) || is(W == dchar))

Yeah, I tend to forget that template specialization even exists in D, and I
_really_ hate the fact that : in template specializations doesn't mean what
it means in is expressions (equality instead of implicit conversion). So, I
wish that we didn't even have template specializations, but presumably, it's
not worth the breakage to remove them. The one thing that they do have going
for them over template constraints though is that if you overload with
template constraints, you tend to have to duplicate the constraint with the
reverse condition, which you don't have to do with template specializations.
But smart use of static ifs inside of templated functions can mitigate that
problem, and ultimately, I think that template specialization is a redundant
feature.

> > It would be good to get comments and suggestions before I write a DIP.
>
> An effective way of improving the state of affairs would be to create a
> PR that makes the constraint easier to read and write, e.g.:
>
> among!(R, double, int) && among!(W, string, char, dchar)
>
> In fact it's surprising it hasn't been proposed yet.

On seeing this thread, that's the first thing I thought of as well, and I
assumed that it already existed but didn't take the time to track it down.
Off the top of my head, I'd guess that you'd use staticIndexOf an check for
-1 to implement it, which should be pretty straight forward, albeit slightly
more verbose. Thinking on it now, I think that that's what I've done in the
past.

- Jonathan M Davis

Re: Exception handling

[Ali Çehreli via Digitalmars-d-learn]

On 07/14/2017 12:36 PM, ANtlord wrote:
> Hello! I've tried to use nothrow keyword and I couldn't get a state of
> function satisfied the keyword. I have one more method that can throw an
> exception; it is called inside nothrow method. Every type of an
> exception from the throwable method is handled by the nothow method.
>
> ubyte throwable_fn(ubyte state) {
> if(state < 2) {
> return 1;
> } else if(state == 3) {
> throw new MyException1("qwe");
> } else {
> throw new MyException2("asd");
> }
> }

Although it's obvious to us that there are only those two exceptions, 
the compiler cannot in general know that.


> void nothrowable_fn() nothrow {
> try {
> auto val = throwable_fn(3);
> // do success staff
> } catch(MyException1 e) {
> // handle error 1
> } catch(MyException2 e) {
> // handle error 2
> }

All you need is to catch Exception there as well:

catch(Exception) {
assert(false, "throwable_fn threw something unexpected");
}

Ali

Re: sorting a string

[Anton Fediushin via Digitalmars-d-learn]

On Friday, 14 July 2017 at 17:23:41 UTC, Steven Schveighoffer 
wrote:
Don't do this, because it's not what you think. It's not 
actually calling std.algorithm.sort, but the builtin array sort 
property. This will be going away soon.


This sucks. I know, that `.sort` will be removed, but I thought 
it won't break any code.


With 2.075, it won't compile even without the parentheses, 
because a char[] is not an array according to std.algorithm...


But why? This should be true for `char[]`, isn't it?
-
if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range 
|| hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
hasAssignableElements!Range) && isRandomAccessRange!Range && 
hasSlicing!Range && hasLength!Range)

-
(It's from 
https://dlang.org/phobos/std_algorithm_sorting.html#sort)

Re: Request for a more powerful template specialization feature

[Andrei Alexandrescu via Digitalmars-d]

On 7/14/17 2:19 PM, data pulverizer wrote:

template Construct(R: Union{double, int}, W: Union{string, char, dchar})


template Construct(R, W)
if ((is(R == double) || is(R == int))
&& (is(W == string) || is(W == char) || is(W == dchar))


It would be good to get comments and suggestions before I write a DIP.


An effective way of improving the state of affairs would be to create a 
PR that makes the constraint easier to read and write, e.g.:


among!(R, double, int) && among!(W, string, char, dchar)

In fact it's surprising it hasn't been proposed yet.

Andrei

Exception handling

[ANtlord via Digitalmars-d-learn]

Hello! I've tried to use nothrow keyword and I couldn't get a 
state of function satisfied the keyword. I have one more method 
that can throw an exception; it is called inside nothrow method. 
Every type of an exception from the throwable method is handled 
by the nothow method.


ubyte throwable_fn(ubyte state) {
if(state < 2) {
return 1;
} else if(state == 3) {
throw new MyException1("qwe");
} else {
throw new MyException2("asd");
}
}

void nothrowable_fn() nothrow {
try {
auto val = throwable_fn(3);
// do success staff
} catch(MyException1 e) {
// handle error 1
} catch(MyException2 e) {
// handle error 2
}
}


I can't compile this. I get an error says nothrowable_fn function 
can't be nothrow. I get the message until I handle Exception 
class. But it is not appropriate for me because I can get another 
exception of another type. I mean case when code will be updated 
and new exceptions will come with a new piece of code.


How can I achieve nothrow statement without catching of an 
instance of Exception class? Thanks. Sorry if my English is not 
clear.

Re: proposed @noreturn attribute

[Lurker via Digitalmars-d]

On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote:

Example 1: Polymorphism

class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) { 
assert(0); }  };

class EvolvedPenguin : Penguin { override void fly() { ... } };



No matter how you look at it, this code should simply not be 
allowed:


Bird bird = ...;
bird.fly(); // is this return or noreturn?

Penguin penguin = ...;
penguin.fly(); // is this return or noreturn?

In both cases, compiler cannot draw any conclusions about 
return/noreturn and thus I believe such code should not be 
allowed.


And if this is disallowed, a Bottom type would fit again.

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

--- Comment #14 from Nemanja Boric <4bur...@gmail.com> ---
Thank you for writing back and you're very welcome! Thanks for
pointing out to that issue, I'll follow it closely.

--

Re: D easily overlooked?

[Moritz Maxeiner via Digitalmars-d]

On Friday, 14 July 2017 at 15:13:23 UTC, Andrew Chapman wrote:


I agree with the others that having no major company behind 
DLang is not helping from a money/resource/exposure point of 
view.  That said, there must be things we can do as a community 
to help improve the situation.


I can imagine for example that the community could focus on 
particular sectors where D excels, and [...]


The primary issue isn't what *can* be done, but what *is going* 
to be done:
People (including me) can be (reasonably) expected to spend their 
free time on things that interest them; those don't usually 
intersect with things that would make D more popular - not to 
mention that D has still too many internal rough edges for me to 
think making D significantly more popular at this point in time 
is going to help us in the long run. I personally much prefer a 
slow, steady growth until the internals (@nogc, shared, etc.) 
have been sorted out.

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

--- Comment #13 from Jonathan M Davis  ---
I confirm that this works with the latest TrueOS, though I expect that it
wouldn't work on the latest FreeBSD 12, because of the 64-bit inode issue
(whereas even though TrueOS is based on FreeBSD CURRENT, it hasn't pulled in
those changes yet precisely because of the breakage that they cause). That's a
separate bug though: bug #17596.

Thanks!

--

Request for a more powerful template specialization feature

[data pulverizer via Digitalmars-d]

Dear all,

Template specializations are a great feature in D. They allow the 
programmer to create template specializations but they can also 
be a powerful way of constraining templates by implementing only 
the specializations that you need. In contrast template 
constraints can quickly become very complex for the programmer to 
write and reason about.


Template specializations should be extended to allow multiple 
lists of types to be implemented together. For example this ...


template Construct(R: Union{double, int}, W: Union{string, char, 
dchar})

{
auto Construct(R, W)(R r, W w)
{

}
}

The same definition would be allowed for all 6 combinations of 
{double, int} and {string, char, dchar} (and no more! Unless 
specified otherwise and/or more generally). This would remove the 
need to manually write these for all combinations or resort to 
constraints.


In addition for some use cases it is a nicer way of doing unions 
than using the current union keyword. Union{double, int} could be 
a compile-time construct indicating that the type can be either 
an actual double or int. It can replace the use of union in cases 
where you want a substitution of either double or int for this 
Union rather than a union type. In addition, variants return 
variants rather than "properly" typed data.


It would be good to get comments and suggestions before I write a 
DIP.


Thank you in advance.

Re: How to get value of type at CT given only an alias

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/14/17 1:51 PM, FoxyBrown wrote:
Trying to do some tricky stuff but I can't seem to get the value of a 
type(enum in my case, but must work in general).


Basically, given a type T or an alias T(alias preferred), I'd like to be 
able to get the "default value" of that type.


e.g.,

if it is an enum and I have an alias to a member, instead of (Enum)3 I 
want 3.


if it is a member field, I want the default value.

if it is a function pointer, the address(probably 0, but whatever).

Basically a sort of generic "getValue" that attempts to get the CT value 
of any type, if it exists. (obviously the value of class is meaningless, 
so returns ""... class isn't even a type, but can still query).


In fact, I'd like to also naturally resolve the value back in to the 
expression that created it.


e.g.,

(Enum)3 -> Enum.ThirdEntry




.init is the default value.

I'm not sure you can get the default value of a non-default initializer, 
My attempts using init didn't work. e.g.:


void foo(alias T)()
{
   pragma(msg, T.init);
}

struct S
{
   int y = 5;
   void bar() { foo!y; } // prints 0
}

-Steve

Code Construction

[James Dean via Digitalmars-d-learn]

Heres a module I just started working on, completely 
incompletely, but demonstrates an ideas that might be very useful 
in D: Code Construction.


The idea is very simple: We have code strings like "class 
%%name%% { }"


and %%name%% is replaced with the name of a type T.

The idea is that we can map a type to a code string and have the 
type "fill in the blanks" rather than having to do it all in D, 
which is far more verbose and terse, we can do it using a 
different method.


Eventually the idea is that we can take any type T, map it in to 
a code string, then map that string to a new type that relates to 
T.


What I use this for is to simplify generating related members.

enum eState
{
Ready,
Starting,
Running,
Pausing,
Paused,
Unpausing,
Stopping,   
Stopped,
Finished,
}


Can be used to generate new stuff:


mixin(sCodeConstruction.MemberMap!("\t\tsMultiCallback!callbackSignature 
Callback_%%name%%;\n", eState));

Generates the following code:

sMultiCallback!callbackSignature Callback_Ready;
sMultiCallback!callbackSignature Callback_Starting;
sMultiCallback!callbackSignature Callback_Running;
sMultiCallback!callbackSignature Callback_Pausing;
sMultiCallback!callbackSignature Callback_Paused;
sMultiCallback!callbackSignature Callback_Unpausing;
sMultiCallback!callbackSignature Callback_Stopping;
sMultiCallback!callbackSignature Callback_Stopped;
sMultiCallback!callbackSignature Callback_Finished;


and if the enum changes, one does not have to regenerate the 
callbacks. (Obviously this is a simple case and D can handle this 
reasonably easily, but the more complex cases are far more 
verbose than what can be done by substitutions)


Using a substitution grammar is a lot easier IMO and D needs 
something like. Unfortunately, I won't be finishing it anytime 
soon so I thought I'd mention the idea and maybe someone else 
could tackle it.




module mCodeConstruction;
import std.meta, std.traits, std.string, std.algorithm, 
std.array, std.conv;




/*
Code construction that simplifies common tasks. 
*/

struct sCodeConstruction
{
		//[ For examples, let X in myModule.myClass.X represents the 
member `int X = 4;` and Y in myModule.myClass.Y be `bool Y(double 
q)`]

public static:
enum Tokens : string
{
		Name= "%%name%%",	// The member name (X => "X", Y => 
"Y")
		FullName			= "%%fullName%%",// The full member name (X => 
"myClass.X", Y => "myClass.Y")
		CompleteName		= "%%completeName%%",			// The complete member 
name (X => "myModule.myClass.X", Y => "myModule.myClass.Y")
		Value= "%%value%%",	// The default value of the member 
(X => 4, Y => "")
		Type= "%%type%%",	// The type of the member (X => int, 
Y => bool delegate(double))
		Module= "%%module%%",	// The module the member is in (X 
=> "myModule", Y => "myModule")
		ParentType			= "%%parentType%%",// The type of the parent 
(X => "class", Y => "class")
		MethodReturn		= "%%method/return%%",			// The return type of a 
member if it has one (X => "", Y => "bool")
		MethodParamNName	= "%%methodParam/N/Name%%",		// The Nth 
parameter's name (Y => "q")
		MethodParamNType	= "%%methodParam/N/type%%",		// The Nth 
parameter's type (Y => "double")

DoublePercent   = "%%%",
  // the %% symbol
}


/*
		A Resolver is a function takes a grammar symbol and returns the 
corresponding element for it from T.

The following list of resolvers are provided for common use:

		MemberResolver: Resolves member information: 
MemeberResolver("%%name%%", myClass.X) = "X".

*/
auto MemberResolver(string S, alias T)()
{
mixin("import "~moduleName!(T)~";");
mixin("alias val = " ~ fullyQualifiedName!(T) ~ ";");

switch(S)
{
case Tokens.Name : return to!string( 
__traits(identifier, T));

}

//pragma(msg, name);
		static if (is(typeof(T) == function) || is(typeof(*T) == 
function))

{

// Get the parameters in a (w)string array.
			enum p = split(Parameters!(member).stringof[1..$-1], 
",").map!(n => strip(n));

Tuple!(S,S)[] params;
foreach(a; aliasSeqOf!(p))
{
}
}   

return "";
}

auto StandardResolver(string S, alias 

Re: sorting a string

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/14/17 1:42 PM, Seb wrote:

On Friday, 14 July 2017 at 17:28:29 UTC, Namal wrote:

On Friday, 14 July 2017 at 16:43:42 UTC, Anton Fediushin wrote:

On Friday, 14 July 2017 at 15:56:49 UTC, Namal wrote:
Thx Steve! By sorting string I mean a function or series of 
functions that sorts a string by ASCII code, "cabA" to "Aabc" for 
instance.


import std.algorithm : sort;
import std.stdio : writeln;

"cabA".dup.sort.writeln;

`dup` is used, because string cannot be modified, so a copy of string 
used instead.


Thx alot. One final question. If I do it like that. I get a 
deprrecation warning:


use std.algorithm.sort instead of .sort property

Wasn't .sort() the proper way to use it, no? Because that won't compile.


With 2.075 you want need this anymore, as the builtin properties have 
finally been removeD:


https://dlang.org/changelog/2.075.0_pre.html#removeArrayProps


With 2.075, it won't compile even without the parentheses, because a 
char[] is not an array according to std.algorithm...


See my other post.

-Steve

How to get value of type at CT given only an alias

[FoxyBrown via Digitalmars-d-learn]

Trying to do some tricky stuff but I can't seem to get the value 
of a type(enum in my case, but must work in general).


Basically, given a type T or an alias T(alias preferred), I'd 
like to be able to get the "default value" of that type.


e.g.,

if it is an enum and I have an alias to a member, instead of 
(Enum)3 I want 3.


if it is a member field, I want the default value.

if it is a function pointer, the address(probably 0, but 
whatever).


Basically a sort of generic "getValue" that attempts to get the 
CT value of any type, if it exists. (obviously the value of class 
is meaningless, so returns ""... class isn't even a type, but can 
still query).


In fact, I'd like to also naturally resolve the value back in to 
the expression that created it.


e.g.,

(Enum)3 -> Enum.ThirdEntry

Re: sorting a string

[Seb via Digitalmars-d-learn]

On Friday, 14 July 2017 at 17:28:29 UTC, Namal wrote:

On Friday, 14 July 2017 at 16:43:42 UTC, Anton Fediushin wrote:

On Friday, 14 July 2017 at 15:56:49 UTC, Namal wrote:
Thx Steve! By sorting string I mean a function or series of 
functions that sorts a string by ASCII code, "cabA" to "Aabc" 
for instance.


import std.algorithm : sort;
import std.stdio : writeln;

"cabA".dup.sort.writeln;

`dup` is used, because string cannot be modified, so a copy of 
string used instead.


Thx alot. One final question. If I do it like that. I get a 
deprrecation warning:


use std.algorithm.sort instead of .sort property

Wasn't .sort() the proper way to use it, no? Because that won't 
compile.


With 2.075 you want need this anymore, as the builtin properties 
have finally been removeD:


https://dlang.org/changelog/2.075.0_pre.html#removeArrayProps

Re: DIP 1011--extern(delegate)--Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 7/14/17 1:18 PM, Jonathan Marler wrote:

On Friday, 14 July 2017 at 12:52:56 UTC, Steven Schveighoffer wrote:

On 7/14/17 6:43 AM, Mike Parker wrote:

DIP 1011 is titled "extern(delegate)".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

All review-related feedback on and discussion of the DIP should occur 
in this thread. The review period will end at 11:59 PM ET on July 28 
(3:59 AM GMT July 29), or when I make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, the DIP 
will be scheduled for another round. Otherwise, it will be queued for 
the formal review and evaluation by the language authors.


Thanks in advance to all who participate.

Destroy!


It seems reasonable.

One concern I have is this:

extern(delegate) ref int foo(ref int x) { return x; }

int x;

auto dg =  // is dg an int * or a delegate?

Currently, this means the former. I'm concerned about ambiguities and 
how to resolve them if all of a sudden someone decides it's a good 
idea to change their functions to extern(delegate), and code like this 
silently switches over. Or someone tries to form a delegate from one 
of these, but instead ends up calling the function instead.




I thought about this use case and it's an interesting one.

TLDR; it should return "int delegate()" not "int*"


I can say from experience, this can wreak havoc on things like template 
constraints. Changing behavior subtly for the same syntax has consequences.


I wonder if there should be a deprecation period. It's an odd case, 
because it only happens if the declaration is changed to 
extern(delegate), which means before the change would be introduced, no 
code would break.


But I fully see quite a few people doing this because people write a lot 
of UFCS functions these days, and slapping an extern(delegate): label 
for these functions might be just the blunt instrument people reach for.


I also see people doing  without realizing it's not 
going to create a delegate. It may be obvious to the compiler that it's 
wrong, so they may still get an error. Where I see possible problems is 
things like template constraints (e.g. if(is(typeof() == int *)) )


However, we do have precedent that  is different for @property 
functions vs. normal ones, so there is some validity to your chosen 
path. And the opposite choice (int *) would make it impossible to take a 
delegate to such a function.


-Steve

Re: sorting a string

[Namal via Digitalmars-d-learn]

On Friday, 14 July 2017 at 16:43:42 UTC, Anton Fediushin wrote:

On Friday, 14 July 2017 at 15:56:49 UTC, Namal wrote:
Thx Steve! By sorting string I mean a function or series of 
functions that sorts a string by ASCII code, "cabA" to "Aabc" 
for instance.


import std.algorithm : sort;
import std.stdio : writeln;

"cabA".dup.sort.writeln;

`dup` is used, because string cannot be modified, so a copy of 
string used instead.


Thx alot. One final question. If I do it like that. I get a 
deprrecation warning:


use std.algorithm.sort instead of .sort property

Wasn't .sort() the proper way to use it, no? Because that won't 
compile.

Re: Need help to get OpenSSL 64 work on Windows x64 | I hate D's GC!

[Suliman via Digitalmars-d-learn]

On Friday, 14 July 2017 at 14:50:04 UTC, bauss wrote:

On Friday, 14 July 2017 at 13:16:17 UTC, Suliman wrote:
It's look that GC in D is really suxx. There is already second 
toy-project where I am getting stuck on Windows with D for 
last 3 month.


I'm using 32-bit build, because I can't understand which libs 
I should use to get OpenSSL 64 bit work with dlang-request.


32-bit version compile and works fine, but it's fail during 
downloading 300MB file with next error:
core.exception.OutOfMemoryError@src\core\exception.d(696): 
Memory allocation failed


You might wanna read the file in chunks and write in chunks.


It's helped, but it's obviously that D on Windows should have 
64-bit linker out of the box. Because GC on 32-bit machine show a 
lot of bugs.

Re: sorting a string

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/14/17 12:43 PM, Anton Fediushin wrote:

On Friday, 14 July 2017 at 15:56:49 UTC, Namal wrote:
Thx Steve! By sorting string I mean a function or series of functions 
that sorts a string by ASCII code, "cabA" to "Aabc" for instance.


import std.algorithm : sort;
import std.stdio : writeln;

"cabA".dup.sort.writeln;

`dup` is used, because string cannot be modified, so a copy of string 
used instead.


Don't do this, because it's not what you think. It's not actually 
calling std.algorithm.sort, but the builtin array sort property. This 
will be going away soon.


Annoyingly, because of autodecoding, you have to cast to ubytes via 
representation to do it the "proper" way:


import std.string: representation, assumeUTF;
import std.algorithm: sort;

auto bytes = line.representation.dup;
bytes.sort;
auto result = bytes.assumeUTF; // result is now char[]

-Steve

Re: DIP 1011--extern(delegate)--Preliminary Review Round 1

[Jonathan Marler via Digitalmars-d]

On Friday, 14 July 2017 at 12:52:56 UTC, Steven Schveighoffer 
wrote:

On 7/14/17 6:43 AM, Mike Parker wrote:

DIP 1011 is titled "extern(delegate)".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

All review-related feedback on and discussion of the DIP 
should occur in this thread. The review period will end at 
11:59 PM ET on July 28 (3:59 AM GMT July 29), or when I make a 
post declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it 
will be queued for the formal review and evaluation by the 
language authors.


Thanks in advance to all who participate.

Destroy!


It seems reasonable.

One concern I have is this:

extern(delegate) ref int foo(ref int x) { return x; }

int x;

auto dg =  // is dg an int * or a delegate?

Currently, this means the former. I'm concerned about 
ambiguities and how to resolve them if all of a sudden someone 
decides it's a good idea to change their functions to 
extern(delegate), and code like this silently switches over. Or 
someone tries to form a delegate from one of these, but instead 
ends up calling the function instead.


-Steve


I thought about this use case and it's an interesting one.

TLDR; it should return "int delegate()" not "int*"

First I want to say this use case happens less often then you 
might think. It's only a problem when the function has no 
arguments. If the function does have arguments then omitting the 
parameter list clearly means the application wants a 
delegate/function pointer. Currently, taking the address of a 
member function call will return a delegate, even if it returns a 
reference.


import std.stdio;
struct Foo
{
static int staticInt;
ref int bar()
{
return staticInt;
}
}

Foo foo;
writeln(typeid()); // prints "int delegate()"

// NOTE: If you want to take the address of the return value, you 
add the () to the call, i.e.

writeln(typeid(())); // prints "int*"

Furthermore, since taking the address of a UFCS call currently 
has no meaning, this would evaluate to int* if it was a UFCS call:


ref int baz(ref Foo foo)
{
static int staticInt;
return staticInt;
}
writeln(typeid()); // prints "int*"

So the semantic analyzer has a precendence for the '&' operator 
when applied to "dotted" function calls.  It checks if the 
expression could result in a delegate, if not then it falls back 
to taking the address of the return value.


As you have noticed, since extern(delegate) adds meaning to 
taking the address of a UFCS call, the semantic analyzer will now 
be able to create a delegate in a place where it previously 
couldn't.


extern(delegate) ref int baz(ref Foo foo)
{
static int staticInt;
return staticInt;
}
writeln(typeid()); // is it "int*" or "int delegate()"?

The implementation could go either way but I think it should be 
consistent with the semantics for delegates meaning it should 
result in "int delegate()" and here's why:


  * Having an inconsistent precedence for member functions and 
extern(delegate) functions would be confusing


  * If taking the address of the return value has precendence, we 
would have to come up with a new syntax when the application 
wants to do the opposite.  Currently, if the application really 
means they want to take the address of the return value, they can 
simply add an empty parameter list to disambiguate the meaning, 
i.e. they could use () instead of   If we used 
the opposite precedence, there is currently no way to say we 
really want a delegate instead of taking the address of the 
return value.


  * If an existing project does start using extern(delegate), in 
almost all cases the change from taking the address of the return 
value to getting a delegate will almost always result in a 
compile time error.  In your example if the meaning of  
changed, it would return a different type which would very likely 
be caught by the compiler, depending of course on how the value 
is used.  There are cases where it wouldn't be caught, but it's 
very unlikely.


  * This only affects code that goes back and modifies their 
application to use extern(delegate).  In other words, it's not 
breaking existing code unless that existing code itself changes 
to use this feature.

Re: DIP 1011--extern(delegate)--Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 7/14/17 1:02 PM, Dmitry Olshansky wrote:

On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:

DIP 1011 is titled "extern(delegate)".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md



  Contrary to  other poster I believe this is wrong way to solve a 
problem. A far simpler approach is to allow compiler implicitly convert 
function pointer to delegate. The dance with making an ABI wrapper can 
be left to compiler proper.


And no annotation hell.


But I think the idea is to avoid the extra indirection and call, no? We 
already have toDelegate, which works fine if you don't care about that.


-Steve

Re: std.container.array of struct inside a struct fails

[drug via Digitalmars-d-learn]

14.07.2017 19:53, Anton Fediushin пишет:

On Friday, 14 July 2017 at 16:42:59 UTC, drug wrote:

It's because Array(T) is a value type and needs type size to define
itself, so you have expected forward reference. But T[] is reference
type and its size is known in advance - it doesn't depend on type,
it's always pointer.sizeof + length.sizeof, for 64x architecture it is
16 bytes, so in this case you have no the issue.
It's not a bug at all.


Thank you!

You're welcome!

[Issue 17541] Function attribute deduction depends on compile invocation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17541

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||wrong-code

--

Re: DIP 1011--extern(delegate)--Preliminary Review Round 1

[Dmitry Olshansky via Digitalmars-d]

On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:

DIP 1011 is titled "extern(delegate)".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md



 Contrary to  other poster I believe this is wrong way to solve a 
problem. A far simpler approach is to allow compiler implicitly 
convert function pointer to delegate. The dance with making an 
ABI wrapper can be left to compiler proper.


And no annotation hell.

---
Dmitry Olshansky

Function attribute deduction depends on compile invocation

[Johan Engelen via Digitalmars-d]

The frontend is automatically deducing things like @nogc and 
nothrow, but it is flaky and results in linker errors for a 
complex codebase (Weka's).


What happens in that in one kind of compilation, @nogc is deduced 
for a function. But in another compilation, it isn't. Thus 
references to the function will have the wrong mangling, and 
linker errors happen:

https://issues.dlang.org/show_bug.cgi?id=17541

This is blocking upgrading to a newer compiler with a newer 
frontend (2.071 --> 2.073).
(I already have a large amount of work arounds... Also non-user 
functions have this problem, e.g. there is a nothrow deduction 
problem for __fieldPostblit.)


Thanks for looking into this bug.

- Johan

Re: D easily overlooked?

[bpr via Digitalmars-d]

On Friday, 14 July 2017 at 09:02:58 UTC, Stefan Koch wrote:

The beauty of D lies in it's holistic approach.

The one unique feature to point out would be CTFE which is not 
to be found in other compiled langauges.


CTFE is found in Nim, as well as inline assembler. Relatively 
easy to use AST macros are also found in Nim.


I don't know another language with full D-like scope guards.

I agree that it's the combination of features that make D 
appealing. I generally think of D as "C++ done righter" and don't 
think about specific unique features.

Re: std.container.array of struct inside a struct fails

[Anton Fediushin via Digitalmars-d-learn]

On Friday, 14 July 2017 at 16:42:59 UTC, drug wrote:
It's because Array(T) is a value type and needs type size to 
define itself, so you have expected forward reference. But T[] 
is reference type and its size is known in advance - it doesn't 
depend on type, it's always pointer.sizeof + length.sizeof, for 
64x architecture it is 16 bytes, so in this case you have no 
the issue.

It's not a bug at all.


Thank you!

[Issue 17541] Function attribute deduction depends on compile invocation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17541

--- Comment #4 from johanenge...@weka.io ---
This problem is bigger than just templates.
I am seeing more and more deduction errors, resulting in linker errors.

--

Re: sorting a string

[Anton Fediushin via Digitalmars-d-learn]

On Friday, 14 July 2017 at 15:56:49 UTC, Namal wrote:
Thx Steve! By sorting string I mean a function or series of 
functions that sorts a string by ASCII code, "cabA" to "Aabc" 
for instance.


import std.algorithm : sort;
import std.stdio : writeln;

"cabA".dup.sort.writeln;

`dup` is used, because string cannot be modified, so a copy of 
string used instead.

Re: std.container.array of struct inside a struct fails

[drug via Digitalmars-d-learn]

14.07.2017 19:12, Anton Fediushin пишет:

This code:
-
import std.container.array;

struct Test {
Array!Test t;
}
-

Fails with an error:
-
/usr/include/dlang/dmd/std/traits.d(2404): Error: struct arrayissue.Test
no size because of forward reference

It's because Array(T) is a value type and needs type size to define 
itself, so you have expected forward reference. But T[] is reference 
type and its size is known in advance - it doesn't depend on type, it's 
always pointer.sizeof + length.sizeof, for 64x architecture it is 16 
bytes, so in this case you have no the issue.

It's not a bug at all.

[Issue 17541] Function attribute deduction depends on compile invocation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17541

johanenge...@weka.io changed:

   What|Removed |Added

Summary|Template attribute  |Function attribute
   |deduction depends on|deduction depends on
   |compile invocation  |compile invocation

--

std.container.array of struct inside a struct fails

[Anton Fediushin via Digitalmars-d-learn]

This code:
-
import std.container.array;

struct Test {
Array!Test t;
}
-

Fails with an error:
-
/usr/include/dlang/dmd/std/traits.d(2404): Error: struct 
arrayissue.Test no size because of forward reference
/usr/include/dlang/dmd/std/traits.d(3462): Error: template 
instance std.traits.FieldTypeTuple!(Test) error instantiating
/usr/include/dlang/dmd/std/container/array.d(276):
instantiated from here: hasElaborateDestructor!(Test)

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/container/array.d(280): Error: 
template instance std.traits.hasIndirections!(Test) error 
instantiating

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/traits.d(2613): Error: template 
instance std.traits.RepresentationTypeTuple!(Test) error 
instantiating
/usr/include/dlang/dmd/std/traits.d(2934):instantiated 
from here: hasRawAliasing!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1362):
instantiated from here: hasAliasing!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1206):
instantiated from here: moveEmplace!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1200):... 
(3 instantiations, -v to show) ...
/usr/include/dlang/dmd/std/container/array.d(487):
instantiated from here: RangeT!(Array!(Test))

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/traits.d(2934): Error: template 
instance std.traits.hasObjects!(Test) error instantiating
/usr/include/dlang/dmd/std/algorithm/mutation.d(1362):
instantiated from here: hasAliasing!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1206):
instantiated from here: moveEmplace!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1200):
instantiated from here: moveImpl!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1162):... 
(2 instantiations, -v to show) ...
/usr/include/dlang/dmd/std/container/array.d(487):
instantiated from here: RangeT!(Array!(Test))

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1372): Error: 
template instance std.traits.hasElaborateAssign!(Test) error 
instantiating
/usr/include/dlang/dmd/std/algorithm/mutation.d(1206):
instantiated from here: moveEmplace!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1200):
instantiated from here: moveImpl!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1162):
instantiated from here: trustedMoveImpl!(Test)
/usr/include/dlang/dmd/std/container/array.d(148):... (1 
instantiations, -v to show) ...
/usr/include/dlang/dmd/std/container/array.d(487):
instantiated from here: RangeT!(Array!(Test))

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1379): Error: 
template instance std.traits.hasElaborateCopyConstructor!(Test) 
error instantiating
/usr/include/dlang/dmd/std/algorithm/mutation.d(1206):
instantiated from here: moveEmplace!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1200):
instantiated from here: moveImpl!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1162):
instantiated from here: trustedMoveImpl!(Test)
/usr/include/dlang/dmd/std/container/array.d(148):... (1 
instantiations, -v to show) ...
/usr/include/dlang/dmd/std/container/array.d(487):
instantiated from here: RangeT!(Array!(Test))

arrayissue.d(4):instantiated from here: Array!(Test)
-

But if I use `Test[] t;` instead, everything is fine.

Also, same code with `class` instead of `struct` works fine, and 
using `union` produces this error message:

-
/usr/include/dlang/dmd/std/traits.d(2404): Error: union 
arrayissue.Test no size because of forward reference
/usr/include/dlang/dmd/std/traits.d(3025): Error: template 
instance std.traits.FieldTypeTuple!(Test) error instantiating
/usr/include/dlang/dmd/std/container/array.d(280):
instantiated from here: hasIndirections!(Test)

arrayissue.d(4):instantiated from here: Array!(Test)
/usr/include/dlang/dmd/std/traits.d(2613): Error: template 
instance std.traits.RepresentationTypeTuple!(Test) error 
instantiating
/usr/include/dlang/dmd/std/traits.d(2934):instantiated 
from here: hasRawAliasing!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1362):
instantiated from here: hasAliasing!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1206):
instantiated from here: moveEmplace!(Test)
/usr/include/dlang/dmd/std/algorithm/mutation.d(1200):... 
(3 instantiations, -v to show) ...
/usr/include/dlang/dmd/std/container/array.d(487):
instantiated from here: RangeT!(Array!(Test))

arrayissue.d(4):instantiated from here: Array!(Test)



So, is it a bug, which should be fixed or it cannot be 
implemented at all? In this case it should be documented.

Re: D easily overlooked?

[Emil via Digitalmars-d]

On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote:

https://blog.sourced.tech/post/language_migrations/

A recent article where github programming languages popularity


Are you aware this is a github infomercial ? That is how 
gamification works: make you compete  over who has the most 
github repos or more migration or whatevers, but the important 
part is making github keep the score :)


This is not about language popularity but about language 
popularity on github. Moreover while charts are nice we don't 
have a "other" category so we don't really see if the languages 
listed cover 90% of github repos or 50% of github repos. Even 
more, if you used github you know the language the project gets 
listed under by default is rather random: if you have js files it 
might get listed under js, if you have C files it might get 
listed under C: for example the rather large migration of Perl 
programmers to C is very probably just Perl modules adding XS 
components.



So don't stress and keep using D ;)

[Issue 16232] std.experimental.logger.core.sharedLog isn't thread-safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16232

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Robert Schadek from comment #3)
> I will add a comment to make that clear

Reopening. I think a comment isn't enough. sharedLog is marked as @safe, but it
effectively casts shared away, which isn't safe. It can lead to memory
corruption when shared data can be accessed as unshared.

I see two ways out:
1) Make sharedLog @system.
2) Return a shared Logger.

Lengthy example of @safe violation with custom Logger:


import std.experimental.logger.core: Logger, LogLevel, sharedLog;

class MyLogger : Logger
{
ulong* p;

this() @safe
{
super(LogLevel.all);

/* Allocate a ulong that disrespects cache line boundaries (64 bytes),
so that it won't be loaded/stored atomically. */
align(64) static struct S
{
align(1):
ubyte[60] off;
ulong x = 0;
}
auto s = new S;
this.p = 
assert((cast(size_t) p) % 64 == 60);
assert((cast(size_t) p) % s.x.sizeof == 4);
}

override void writeLogMsg(ref LogEntry payload) @safe { assert(false); }
/* never called */
}

MyLogger sharedMyLogger() @safe
{
Logger logger = sharedLog();
return cast(MyLogger) logger;
/* This is a simple downcast. Not casting away shared. */
}

enum n = 1_000_000;

/* Toggle *p between 0 and ulong.max (n times). */
void write(ulong* p) @safe
{
foreach (i; 0 .. n) *p = ~*p; /* non-atomic load and store */
}

/* Assert that *p is either 0 or ulong.max (n times). */
void read(ulong* p) @safe
{
import std.conv: to;

foreach (i; 0 .. n)
{
ulong val = *p; /* non-atomic load */
assert(val == 0 || val == ulong.max, val.to!string(16)); /* fails */
}
}

void main()
{
sharedLog = new MyLogger;

/* Read and write concurrently. `read` will see a partially written value.
I.e., memory corruption. */
import core.thread: Thread;
new Thread(() @safe { write(sharedMyLogger.p); }).start();
read(sharedMyLogger.p);
}


--

Re: sorting a string

[Namal via Digitalmars-d-learn]

On Friday, 14 July 2017 at 15:15:42 UTC, Steven Schveighoffer 
wrote:




import std.algorithm: filter;
import std.uni: isWhite;

line.filter!(c => !c.isWhite).to!string;

be warned, this is going to be a bit slow, but that's the cost 
of autodecoding.


If you are looking for just removing ascii whitespace, you can 
do it a bit more efficiently, but it's not easy.


About the string sorting, you'd have to be more specific.

-Steve


Thx Steve! By sorting string I mean a function or series of 
functions that sorts a string by ASCII code, "cabA" to "Aabc" for 
instance.

Re: proposed @noreturn attribute

[Guillaume Boucher via Digitalmars-d]

On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote:

1)@noreturn
2)@disable(return)
3)none

w.r.t optimisation assuming both 1 & 3  impact DMD equally [...]


I don't think that's true.  A Bottom type does not cover all use 
cases of @noreturn/@pragma(noreturn).


Example 1: Polymorphism

class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) { 
assert(0); }  };

class EvolvedPenguin : Penguin { override void fly() { ... } };

There's no way to encode that information in a return type.

Example 2: Compile-time polymorphism

Same as above, except during compile time.  While it looks ok in 
theory (just return Bottom, and everything is alright), it seems 
very tricky to get right.  Example from checkedint.d:


auto r = hook.hookOpUnary!op(payload);
return Checked!(typeof(r), Hook)(r);

Let's say the hook refuses to perform hookOpUnary, so r is 
Bottom.  Unfortunately, Checked!(Bottom, Hook)(r) doesn't compile 
(because "if (isIntegral!T || is(T == Checked!(U, H), U, H))" 
fails).  While Bottom may be substituted into all expressions 
(which doesn't seem easy anyway), it for sure can't be inserted 
as any template argument.  As seen before, Checked is not 
Bottom-proof.  I would think that most templates are not 
Bottom-proof and making them Bottom-proof seems quite a bit of 
work.


With @pragma(noreturn) that situation would be no problem.

Example 3: Unreachable statements/Implicit noreturn inference

As pointed out by Steven Schveighoffer, the current 
unreachability errors should probably be removed in generic code.


If we do that, then generic functions can be @pragma(noreturn) if 
certain conditions are met.  A compiler can easily figure that 
out, but writing it inside static ifs could be almost impossible.


Assume we have a hook to Checked that disallows casts.  Current 
signature:


U opCast(U, this _)() if (isIntegral!U || isFloatingPoint!U || 
is(U == bool))


The compiler can figure out that all code paths end with an 
@pragma(noreturn), so it can add that pragma implicitly to the 
signature.  However, the compiler can't change the return type 
from U to Bottom (otherwise static equality checks with U will 
fail).

[Issue 17652] New: [DIP1000] opApply allow to escape reference to scope variable

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17652

  Issue ID: 17652
   Summary: [DIP1000]  opApply allow to escape reference to scope
variable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mathias.l...@sociomantic.com

```
void main () @safe @nogc
{
Object o = leak();
assert(o !is null);
}

Object leak () @safe @nogc
{
Foo f;
foreach (object; f)
if (object !is null)
return object;
return null;
}

struct Foo
{
alias DgType = int delegate (scope Object) @safe @nogc;
public int opApply (scope DgType dg) @safe @nogc
{
scope o = new Object;
return dg(o);
}
}
```

The compiler doesn't properly check the type of the delegate it passes to
`opApply`, allowing to pass a delegate which needs a non-scope parameter.

--

Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)

[rikki cattermole via Digitalmars-d-announce]

On 14/07/2017 4:01 PM, Vitor Rozsas wrote:

On Friday, 14 July 2017 at 14:37:56 UTC, Vitor Rozsas wrote:

On Friday, 14 July 2017 at 14:23:49 UTC, rikki cattermole wrote:

On 14/07/2017 3:17 PM, Vitor Rozsas wrote:

On Friday, 14 July 2017 at 14:10:29 UTC, Vitor Rozsas wrote:

[...]


A transaction would simply change the owner of the cents and not 
create any message in the database.
Change the owner by changing the values (owner) of the keys (cents) 
being transferred.


Blockchains work by making the entire history available to be 
verified and computed against. This is entirely its selling point.

So no, a block chain can never be fixed sized.

After all, how do you know that X owns the coin and not just some 
random node trying to corrupt and steal every bodies coins?


But it's so expensive... Soon, bitcoin will have a whole terabyte to 
be downloaded... So, no deal?

That's sad.


I was thinking of doing something big... An operating system? With 
everything that a user could desire of?
Big projects are necessary, for D to get more... known (and therefore, 
more used).


A phone OS (ARM)?

I heard that DMD will accept ARM very soon. While that doesn't happen, 
there are other compilers for ARM... So a phone OS could be interesting.

A phone OS written in D.

There are kernels done in D already.
But I don't think they are as complete as Linux's for example.


Scale your dreams back a bit.

If you want to put money into anything here is my list:

1. Get shared libraries 100% working, with clear articles on how to use 
it, on every platform.

2. std.experimental.color, it seems Manu is stalled
3. std.experimental.image, ok ok, this one is mine but its about time we 
get the damn interfaces standardized in Phobos!
4. GUI widget rendering library, GUI widget != GUI toolkit (think just 
rendering a single control), basically handles rendering + accessibility.


These are not big projects, but they would go a long way to getting any 
thing really "cool".
Keep in mind, money talks. Getting the right people available to work on 
a project full time for a few months would really speed a lot of this 
stuff up.


There is also other stuff like a bidi library, font rasterizer and other 
more useful infrastructure projects that actually has a chance of being 
completed.


Depending on how far you want to go, my list alone is a few years worth 
of work for a 3-5 people team.

Re: char e string em linguagem D

[crimaniak via Digitalmars-d-learn]

On Thursday, 13 July 2017 at 22:36:47 UTC, Basile B. wrote:

  return cast(char[])`

...
Never cast a literal to char[]. modifying the resulting char[] 
will lead to AV, at least under linux.  `.dup` the literal if 
you really needs char[].


Hmm, yes, my bad. Probably, it was necessary even for this simple 
example to write const char[].

Re: sorting a string

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/14/17 11:06 AM, Namal wrote:
Is there a 'easy' way to sort a string in D like it is possible in 
Python? Also how can I remove whitespace between characters if I am 
reading a line from a file and safe it as a string?


 string[] buffer;

 foreach (line ; File("test.txt").byLine)
 buffer ~= line.to!string;


import std.algorithm: filter;
import std.uni: isWhite;

line.filter!(c => !c.isWhite).to!string;

be warned, this is going to be a bit slow, but that's the cost of 
autodecoding.


If you are looking for just removing ascii whitespace, you can do it a 
bit more efficiently, but it's not easy.


About the string sorting, you'd have to be more specific.

-Steve