Re: Beta D 2.071.2-b3

2016-08-30 Thread ketmar via Digitalmars-d-announce

On Wednesday, 31 August 2016 at 05:23:34 UTC, ketmar wrote:

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:

As in needs private members in __traits(allMembers).


and in the end it just producing excessive noise in common 
loops that does `is(typeof(__traits(getMember, ...)))`. it 
would be better to either leave that alone and allow all 
access, or exclude inaccessible members gin `allMembers` 
completely. yet D choose the third way, combining the worst 
features from both solutions.


oops. seems that i did something wrong with myself. i'm sorry, 
the PR you linked seems to do exactly what i described. dunno how 
i managed to completely misunderstand it.


Re: Beta D 2.071.2-b3

2016-08-30 Thread ketmar via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:

As in needs private members in __traits(allMembers).


and in the end it just producing excessive noise in common loops 
that does `is(typeof(__traits(getMember, ...)))`. it would be 
better to either leave that alone and allow all access, or 
exclude inaccessible members gin `allMembers` completely. yet D 
choose the third way, combining the worst features from both 
solutions.


Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Mike Parker via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 19:44:19 UTC, Jacob Carlborg wrote:


Some of the links have pretty long text, is that intended?


Yes. Joakim submitted the text with the links already formatted 
and I left them in place.


Re: The D Language Foundation is now a tax exempt non-profit organization

2016-08-30 Thread Jon Degenhardt via Digitalmars-d-announce
On Monday, 29 August 2016 at 17:03:34 UTC, Andrei Alexandrescu 
wrote:
We're happy to report that the D Language Foundation is now a 
public charity operating under US Internal Revenue Code Section 
501(c)(3). The decision is retroactive to September 23, 2015.


This has wide-ranging implications, the most important being 
that individuals and organizations may make tax deductible 
bequests, devises, transfers, or gifts to the Foundation. We 
will mull over defining donation and sponsorship packages in 
the near future. If interesting in donating spontaneously, feel 
free to reach out to us via email at foundat...@dlang.org.


Many thanks are due to the folks in this community who asked 
for and supported this initiative.




Fantastic! Congrats, nice work!


Re: Beta D 2.071.2-b3

2016-08-30 Thread Ali Çehreli via Digitalmars-d-announce

On 08/30/2016 04:54 PM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
>> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
>>> I'm a bit sad to see that
>>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
>>> to fix issue 15907. Another decision could have been to break the
>>> visibility for the traits allMember, getMember, derivedMember and
>>> getOverloads.
>>
>> Well there was reasoning to choose that solution instead of the other
>> (https://github.com/dlang/dmd/pull/6078) and the fact that private
>> members aren't accessible (set/get) is a good indication that nobody
>> needs this.
>
> As in needs private members in __traits(allMembers).
>
>> Adding an unsafe facility to access private members is a separate
>> problem, but please see the changelog for how to achieve this already
>> by mixing in templates.
>
> Allowing access to private members has a lot of implications, e.g.
> breaks lots of optimizations b/c you can't know who accesses sth. It's
> also yet unclear what effect this has on @safe and we'd not only have to
> modify visibility but remove the access checks as well. This is clearly
> too much to just fix that problem w/ certain template instantiations,
> none of which should work on private members atm.
> Also you'd have to change a lot of existing code, or it would now just
> operate on private members.

How is this supposed to work? What is the new guideline and who should 
bear the new guideline; the library author or the user?


For this to work, the users must know that the library will call 
__traits(allMembers) so that they mixin and otherwise don't? That would 
be wrong in the other direction, no? The client needing to know about 
the library code? Wrong principle...


What if I add a new private member to my otherwise public struct? Then I 
should remember to mixin all N templates that my module happens to be 
using right now?


The only correct action that I see is that every template must be 
mixed-in in case I have a private member in the future or the library 
implementation may change in the future.


I'm sorry but this is not usable.

Ali

P.S. While I'm on my soapbox, I've started to think private is overrated 
anyway. A system language should allow to bypass that protection. 
private should be a recommendation only.




Re: Beta D 2.071.2-b3

2016-08-30 Thread Basile B. via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:

On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that 
https://issues.dlang.org/show_bug.cgi?id=15371 was completely 
ignored to fix issue 15907. Another decision could have been 
to break the visibility for the traits allMember, getMember, 
derivedMember and getOverloads.


Well there was reasoning to choose that solution instead of the 
other (https://github.com/dlang/dmd/pull/6078) and the fact


I don't understand, which was the other ? the link points to the 
PR that's been merged.


Re: Beta D 2.071.2-b3

2016-08-30 Thread Martin Nowak via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:

On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that 
https://issues.dlang.org/show_bug.cgi?id=15371 was completely 
ignored to fix issue 15907. Another decision could have been 
to break the visibility for the traits allMember, getMember, 
derivedMember and getOverloads.


Well there was reasoning to choose that solution instead of the 
other (https://github.com/dlang/dmd/pull/6078) and the fact 
that private members aren't accessible (set/get) is a good 
indication that nobody needs this.


As in needs private members in __traits(allMembers).

Adding an unsafe facility to access private members is a 
separate problem, but please see the changelog for how to 
achieve this already by mixing in templates.


Allowing access to private members has a lot of implications, 
e.g. breaks lots of optimizations b/c you can't know who accesses 
sth. It's also yet unclear what effect this has on @safe and we'd 
not only have to modify visibility but remove the access checks 
as well. This is clearly too much to just fix that problem w/ 
certain template instantiations, none of which should work on 
private members atm.
Also you'd have to change a lot of existing code, or it would now 
just operate on private members.


Re: Beta D 2.071.2-b3

2016-08-30 Thread Martin Nowak via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that 
https://issues.dlang.org/show_bug.cgi?id=15371 was completely 
ignored to fix issue 15907. Another decision could have been to 
break the visibility for the traits allMember, getMember, 
derivedMember and getOverloads.


Well there was reasoning to choose that solution instead of the 
other (https://github.com/dlang/dmd/pull/6078) and the fact that 
private members aren't accessible (set/get) is a good indication 
that nobody needs this.
Adding an unsafe facility to access private members is a separate 
problem, but please see the changelog for how to achieve this 
already by mixing in templates.


Re: Beta D 2.071.2-b3

2016-08-30 Thread Ali Çehreli via Digitalmars-d-announce

On 08/30/2016 02:58 PM, Basile B. wrote:

On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote:

Third beta for the 2.071.2 release.

This beta fixes spurious deprecation warnings with templates using
getMember (Issue 15907), please read the changelog for more details.

http://dlang.org/changelog/2.071.2.html
http://dlang.org/download.html#dmd_beta

Please report any bugs at https://issues.dlang.org

-Martin


I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371
was completely ignored to fix issue 15907. Another decision could have
been to break the visibility for the traits allMember, getMember,
derivedMember and getOverloads.



+1 I've just opened a discussion thread on the main newsgroup about the 
(un)usability of this fix before seeing your comment.


Ali



Re: Battle-plan for CTFE

2016-08-30 Thread tsbockman via Digitalmars-d-announce

On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
I just came up with a nifty little patch that makes it possible 
to ensure that a function is _only_ used at ctfe.

Or the opposite.

static assert(__ctfe, "This function is not supposed to be 
called outside of ctfe");
and static assert(!__ctfe, "This function is not supposed to be 
called during ctfe");


similarly you can use static if (__ctfe).

Is it worth trying to get it into master ?


Yes, please. I've often wished I could use `__ctfe` in a `static 
if`.




Re: Beta D 2.071.2-b3

2016-08-30 Thread Basile B. via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote:

Third beta for the 2.071.2 release.

This beta fixes spurious deprecation warnings with templates 
using getMember (Issue 15907), please read the changelog for 
more details.


http://dlang.org/changelog/2.071.2.html
http://dlang.org/download.html#dmd_beta

Please report any bugs at https://issues.dlang.org

-Martin


I'm a bit sad to see that 
https://issues.dlang.org/show_bug.cgi?id=15371 was completely 
ignored to fix issue 15907. Another decision could have been to 
break the visibility for the traits allMember, getMember, 
derivedMember and getOverloads.




Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Walter Bright via Digitalmars-d-announce

On 8/30/2016 4:50 AM, Mike Parker wrote:

Joakim has put together an interview with Walter that's all about D. It's an
enjoyable read. You can parse the interview at [1] and visit the reddit thread
at [2]. I anticipate publishing more of Joakim's interviews on the blog in the
future.

[1]
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[2]
https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/



It's also on Hacker News, but access it via the front page rather than this URL, 
otherwise up/downvotes will not count:


https://news.ycombinator.com/item?id=1239047


Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Jacob Carlborg via Digitalmars-d-announce

On 2016-08-30 13:50, Mike Parker wrote:

Joakim has put together an interview with Walter that's all about D.
It's an enjoyable read. You can parse the interview at [1] and visit the
reddit thread at [2]. I anticipate publishing more of Joakim's
interviews on the blog in the future.

[1]
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/


Some of the links have pretty long text, is that intended? For example:

"an early developer of C++ compilers starting from the mid-’80s, 
including the first C++ compiler to translate source code directly to 
object code without using C as an intermediate"


All that is one link.

--
/Jacob Carlborg


Beta D 2.071.2-b3

2016-08-30 Thread Martin Nowak via Digitalmars-d-announce

Third beta for the 2.071.2 release.

This beta fixes spurious deprecation warnings with templates 
using getMember (Issue 15907), please read the changelog for more 
details.


http://dlang.org/changelog/2.071.2.html
http://dlang.org/download.html#dmd_beta

Please report any bugs at https://issues.dlang.org

-Martin



Re: Battle-plan for CTFE

2016-08-30 Thread Stefan Koch via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote:
worth trying to get it into master ?


I would say maybe, but let's keep separate things separate. 
This is a language change. I would not include it in the same 
series of patch that change CTFE behavior.


Yes. It would be confusing. And it is not done with the patch I 
mentioned.


Re: Battle-plan for CTFE

2016-08-30 Thread deadalnix via Digitalmars-d-announce

On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:

On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote:

On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via


The work you are doing is just awesome!
Many thanks.



+1 your work is key for our success as a community.

R


Thanks guys.

I just came up with a nifty little patch that makes it possible 
to ensure that a function is _only_ used at ctfe.

Or the opposite.

static assert(__ctfe, "This function is not supposed to be 
called outside of ctfe");
and static assert(!__ctfe, "This function is not supposed to be 
called during ctfe");


similarly you can use static if (__ctfe).

Is it worth trying to get it into master ?


I would say maybe, but let's keep separate things separate. This 
is a language change. I would not include it in the same series 
of patch that change CTFE behavior.


Re: The D Language Foundation is now a tax exempt non-profit organization

2016-08-30 Thread Dicebot via Digitalmars-d-announce
On 08/30/2016 05:25 PM, Andrei Alexandrescu wrote:
> Unless we have a sort of branch in other countries, I don't see what we
> can do here. -- Andrei

EU branch of D foundation would be interesting but I think it is much
premature to think about that :)



signature.asc
Description: OpenPGP digital signature


Re: The D Language Foundation is now a tax exempt non-profit organization

2016-08-30 Thread Russel Winder via Digitalmars-d-announce
On Tue, 2016-08-30 at 10:25 -0400, Andrei Alexandrescu via Digitalmars-
d-announce wrote:
[…]
> Unless we have a sort of branch in other countries, I don't see what
> we 
> can do here. -- Andrei

Understood, but without a solution it means no-one outside the USA can
contribute and have the D Foundation receive the tax benefit of a
charitable gift. From what I can tell PSF has't bothered to solve this,
it is a USA organisation for USA people. Also I think donations are in
US$, which means non-US$ donors bear the conversion cost. Someone has
to because the banks are not charities, but it is annoying that non US$
donations get "taxed" twice. 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part


Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Mike Parker via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 13:07:03 UTC, Andrea Fontana wrote:



Nice article.

PS: "ABEL" link point to mobile version of wikipedia.

Andrea


Fixed, thanks!


Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Mike Parker via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 13:37:34 UTC, Adam D. Ruppe wrote:

On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:

Joakim has put together an interview


He did four (IIRC) of these for This Week in D too if you want 
more like that:


Sönke Ludwig
http://arsdnet.net/this-week-in-d/mar-15.html

Dmitry Olshansky
http://arsdnet.net/this-week-in-d/jun-28.html

Etienne Cimon
http://arsdnet.net/this-week-in-d/jul-12.html

Atila Neves
http://arsdnet.net/this-week-in-d/sep-06.html


Thanks!


Re: The D Language Foundation is now a tax exempt non-profit organization

2016-08-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 08/30/2016 08:36 AM, Russel Winder via Digitalmars-d-announce wrote:

Andrei,

This is splendid news for the purveying of the D Programming language.
 The question is though: this covers the USA what about the Rest of the
World?

For the language itself it is almost irrelevant where the owning
foundation is located as long as it is a charitable venture in its
jusridiction of incorporation. However for financial issues, the
jurisdiction is critical. Getting USA-wide charitable status is great,
well-done on that, particularly in the context of the atitude of IRS to
charitable foundations a couple of years ago. However the EU and other
parts of the world will not be covered by this, and I am not sure there
is any form of reciprocal arrangement.


Unless we have a sort of branch in other countries, I don't see what we 
can do here. -- Andrei





Re: The D Language Foundation is now a tax exempt non-profit organization

2016-08-30 Thread qznc via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 12:36:12 UTC, Russel Winder wrote:

Andrei,

This is splendid news for the purveying of the D Programming 
language.  The question is though: this covers the USA what 
about the Rest of the World?


For Germany this would probably require a separate application to 
the tax office to become a "gemeinnützige Organisation" 
(charitable organization).


It seems [0] within the EU, it is enough for the donor to proof 
charity by including the charter in the tax declaration, but not 
for the US.


[0] 
https://www.steuertipps.de/anlegen-vererben-spenden/themen/wann-sind-spenden-an-auslaendische-stiftungen-absetzbar




Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Adam D. Ruppe via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:

Joakim has put together an interview


He did four (IIRC) of these for This Week in D too if you want 
more like that:


Sönke Ludwig
http://arsdnet.net/this-week-in-d/mar-15.html

Dmitry Olshansky
http://arsdnet.net/this-week-in-d/jun-28.html

Etienne Cimon
http://arsdnet.net/this-week-in-d/jul-12.html

Atila Neves
http://arsdnet.net/this-week-in-d/sep-06.html


Re: Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Andrea Fontana via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:
Joakim has put together an interview with Walter that's all 
about D. It's an enjoyable read. You can parse the interview at 
[1] and visit the reddit thread at [2]. I anticipate publishing 
more of Joakim's interviews on the blog in the future.


[1] 
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[2] 
https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/


Nice article.

PS: "ABEL" link point to mobile version of wikipedia.

Andrea


Joakim Intreviews Walter for the D Blog

2016-08-30 Thread Mike Parker via Digitalmars-d-announce
Joakim has put together an interview with Walter that's all about 
D. It's an enjoyable read. You can parse the interview at [1] and 
visit the reddit thread at [2]. I anticipate publishing more of 
Joakim's interviews on the blog in the future.


[1] 
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[2] 
https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/


Re: Battle-plan for CTFE

2016-08-30 Thread Johannes Pfau via Digitalmars-d-announce
Am Tue, 30 Aug 2016 12:42:35 +0200
schrieb Johannes Pfau :

> @nogc is only meaningful at runtime. So this could work:
> 
> module foo;
> @nogc:
> [...]
> 
> string ctfeOnly(string name)
> {
> static assert(!__ctfe);

This should be
static assert(__ctfe);
of course.


Re: Battle-plan for CTFE

2016-08-30 Thread Johannes Pfau via Digitalmars-d-announce
Am Tue, 30 Aug 2016 08:35:20 +
schrieb Stefan Koch :

> I do not see how this could affect @nogc.

@nogc is only meaningful at runtime. So this could work:

module foo;
@nogc:
[...]

string ctfeOnly(string name)
{
static assert(!__ctfe);
// error: cannot use operator ~ in @nogc function
return "int " ~ name ~ ";";
}
mixin(ctfeOnly("foo"));


Re: Battle-plan for CTFE

2016-08-30 Thread Rory McGuire via Digitalmars-d-announce
On Tue, Aug 30, 2016 at 10:35 AM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> [snip]
> But yes you can circumvent the code-generation and pulling in the druntime
> dependency using a static if.
>

That will be awesome!


Re: Beta D 2.071.2-b2

2016-08-30 Thread Jack Applegame via Digitalmars-d-announce

On Tuesday, 9 August 2016 at 15:37:27 UTC, Martin Nowak wrote:

Second beta for the 2.071.2 release.

This fixes Issue 15780, 16085, and 16348.
More import/lookup fixes upcoming.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.071.2.html


Please report any bugs at https://issues.dlang.org

- -Martin
Could you consider this 
https://github.com/dlang/phobos/pull/4758, please


Re: Battle-plan for CTFE

2016-08-30 Thread Stefan Koch via Digitalmars-d-announce

On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote:


There are some nice use cases for this:
* Do not enforce @nogc for CTFE only functions, so you can mark 
a

  complete module nogc: and CTFE only functions will get ignored
* Do not emit code for CTFE only functions. This is useful for 
bare
  metal programming: The CTFE only function can depend on 
druntime

  functions not available in the bare metal runtime.

These are common problems when using string mixins: The 
functions
to generate the mixed in code use string manipulation which is 
usually
not @nogc and might require runtime functions. But the code 
generation

function is exclusively used in CTFE.


I do not see how this could affect @nogc.
But yes you can circumvent the code-generation and pulling in the 
druntime dependency using a static if.


Re: Battle-plan for CTFE

2016-08-30 Thread Johannes Pfau via Digitalmars-d-announce
Am Tue, 30 Aug 2016 08:57:25 +0200
schrieb Jacob Carlborg :

> On 2016-08-29 10:39, Stefan Koch wrote:
> 
> > Thanks guys.
> >
> > I just came up with a nifty little patch that makes it possible to
> > ensure that a function is _only_ used at ctfe.
> > Or the opposite.
> >
> > static assert(__ctfe, "This function is not supposed to be called
> > outside of ctfe");
> > and static assert(!__ctfe, "This function is not supposed to be
> > called during ctfe");
> >
> > similarly you can use static if (__ctfe).
> >
> > Is it worth trying to get it into master ?  
> 
> Wow, absolutely :)
> 

There are some nice use cases for this:
* Do not enforce @nogc for CTFE only functions, so you can mark a
  complete module nogc: and CTFE only functions will get ignored
* Do not emit code for CTFE only functions. This is useful for bare
  metal programming: The CTFE only function can depend on druntime
  functions not available in the bare metal runtime.

These are common problems when using string mixins: The functions
to generate the mixed in code use string manipulation which is usually
not @nogc and might require runtime functions. But the code generation
function is exclusively used in CTFE.


Re: Battle-plan for CTFE

2016-08-30 Thread Jacob Carlborg via Digitalmars-d-announce

On 2016-08-29 10:39, Stefan Koch wrote:


Thanks guys.

I just came up with a nifty little patch that makes it possible to
ensure that a function is _only_ used at ctfe.
Or the opposite.

static assert(__ctfe, "This function is not supposed to be called
outside of ctfe");
and static assert(!__ctfe, "This function is not supposed to be called
during ctfe");

similarly you can use static if (__ctfe).

Is it worth trying to get it into master ?


Wow, absolutely :)

--
/Jacob Carlborg