Re: Researcher question – what's the point of semicolons and curly braces?

[Bauss via Digitalmars-d]

On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:

On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

[...]


You realize your bias is showing very strongly in the wording 
of this question, right? I don't agree the naked version is 
clean at all.


[...]



Praise this

[Issue 15988] [REG v2.070] Massive Compile Time Slowdown

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
The OP hasn't well noted that's only the **debug** build which is affected.

--

Re: Researcher question – what's the point of semicolons and curly braces?

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

Would it be difficult to compile the clean version?


You realize your bias is showing very strongly in the wording of 
this question, right? I don't agree the naked version is clean at 
all.


ohimsorryletswritemorecleanlywithoutanyofthatobnoxiouspunctuationnoiseitisalluselessanywaysurelyyoucanstillmakesenseofthisafterallthereareonlysomanywordsintheenglishlanguageandknowinghwatdoesanddoesntmakesenseincontextmeansyoucansurelyparsethisrightout

oh i know you will say thats not a fair comparison it is the 
punctuation you dislike not the spacing though really the same 
principle applies actually while the punctuation does have 
meaning ill concede you can nevertheless parse it without 
although you might then want other rules


see in a lot of those languages they redefine things like lines 
to serve the same role as the punctuation


so like instead of ending expressions in punctuation

they end them with a new line instead

meaning you must hit enter at the point that d would allow you to 
use the semicolon


ditto for indentation

like sure this is readable

but it just bothers me to use as a matter of course

it can even become

~hideous~

crap i cant even use ~ wtf this style of writing sucks it just 
isnt very expressive nor artistic


* * *

Personally, I sometimes do like writing in all lower case without 
punctuation, but I do so as a style choice; it tends to be my way 
of expressing in text that I'm not being entirely serious, in 
contrast to ordinarily formatted text.


Code is the same thing - I will use different styles for 
different situations.


It isn't a terribly difficult technical problem to define a 
programming language to have a different syntax. You can parse 
them without that much trouble.


But the syntax isn't really there for the compiler's benefit 
(though there are benefits there, just like asking the user to 
confirm their email address, getting a bit of redundant 
information out of the human user can help catch mistakes), it is 
there for the reader.


I often get lost when there's several levels of whitespace change 
at once.


def pain:
  if whatever:
do this
if this_too:
  also do this
  if one_more:
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
oh snap this is kinda long
it takes several lines
quick where we at?



Curly braces in there would show we intended to go a couple 
levels and give a convenient place to click to ask our editor 
program to show us where it started too. I really like having 
that.



Semicolons similarly are a nice way to say "I'm done with this 
thought", which I'm just used to hitting. When I use languages 
that don't allow them, I waste quite a bit of time hitting 
backspace after automatically hitting ;!


Moreover, with a longer line, (or in some cases like debug lines 
where I want to easily remove two statements with one keypress - 
yes, my editor can delete a line instantly, but two lines are a 
bit harder to do) the semicolon gives you the freedom to format 
it as you will.



a = 5 +
4 -
1;

That'd work without the semicolon (usually), but this is 
different:


a =   5
+ 4
- 1;


In that case, the line break after the 5 would probably end the 
statement, leaving the other numbers dangling.


I prefer this formatting in many cases though since then the 
operators nicely line up. In the first one, the 4 is visually 
tied to the -, but really, the - is more strongly related to the 
1, so I want them grouped together.



Well, I'm late, but to sum up:

* familiarity brings comfort, to look and in using existing 
workflows like my editor's delete-line feature.


* breaking habits, regardless of whether those habits are perfect 
in a perfect world, is a source of mental friction that has 
higher cost than benefit


* punctuation separate from styling leaves both as independent 
decisions that brings more beauty


It isn't so much that they are necessary, it is that they bring 
various other benefits.




I'm a social scientist and I'm preparing some studies on
the effects of programming language syntax on learning,
motivation to pursue programming, as well as any 
disproportionate effects that PL syntax has on the appeal

of programming to women (more on the latter 

Re: Researcher question – what's the point of semicolons and curly braces?

[Walter Bright via Digitalmars-d]

On 5/2/2016 8:48 PM, Joe Duarte wrote:

Why are curly braces and semicolons necessary? What information do they
carry that a compiler could not otherwise reliably obtain?


You are correct in that they are (mostly) redundant. Some ambiguities 
can arise because D is not a whitespace delimited language. However, the 
real reasons are:


1. Redundancy in specification means the compiler can catch more 'typo' 
mistakes rather than having them compile successfully and then behave 
mysteriously. If a language has 0 redundancy, then any 
8745b48%%&* string would be a valid program. Redundancy is a 
critical feature of high reliability languages.


Many languages have removed redundancy only to put it back in after 
bitter experience. The classic is implicit declaration of variables.


2. The redundancy also means the compiler can 'resync' itself to the 
input once a syntactic error is detected.


3. It's instantly familiar to those who program already in "curly brace" 
languages.

Re: Researcher question – what's the point of semicolons and curly braces?

[rikki cattermole via Digitalmars-d]

On 03/05/2016 3:48 PM, Joe Duarte wrote:

Hi all,

I'm a social scientist and I'm preparing some studies on the effects of
programming language syntax on learning, motivation to pursue
programming, as well as any disproportionate effects that PL syntax has
on the appeal of programming to women (more on the latter in a separate
post).

So I want to get a better idea of the rationale for various syntactical
design decisions, and I'm going to ask you the same question I'll ask
the Rust community:

Why are curly braces and semicolons necessary? What information do they
carry that a compiler could not otherwise reliably obtain?

Here's an example from the D Overview page:


class Foo
{
int foo(Bar c) { return c.bar; }
}

class Bar
{
int bar() { return 3; }
}


Okay, if we remove the curly braces and semicolons, we have:


class Foo

int foo(Bar c) return c.bar


class Bar

int bar() return 3


Would it be difficult to compile the clean version? Would there be
issues with the design of the lexer/parser? I assume the compiler would
recognize keywords like return (and a clean syntax could drive different
rules for what statements and expressions could appear on the same line
and so forth).

In reality, a compiler would see the above with line ending characters
terminating every line (e.g. U+000A), so it would be as line-aware as a
human. I've never built lexers or parsers, much less compilers, so maybe
I'm missing a major implementation hurdle. I'm just thinking that
Facebook has built software that recognizes my face in other people's
pictures, so it seems like building software that understands structured
text would be a solved problem. It puzzles me to see so much apparent
punctuation noise in a 21st-century language (and, to be fair, Rust
puzzles me for the same reasons).

JD


One of the benefits of having semicolons and braces is that you can have 
your entire source file on one line!

But ok in all seriousness as shown by Lua its not really required.
Its a stylistic choice at least for me it is.

Researcher question – what's the point of semicolons and curly braces?

[Joe Duarte via Digitalmars-d]

Hi all,

I'm a social scientist and I'm preparing some studies on the 
effects of programming language syntax on learning, motivation to 
pursue programming, as well as any disproportionate effects that 
PL syntax has on the appeal of programming to women (more on the 
latter in a separate post).


So I want to get a better idea of the rationale for various 
syntactical design decisions, and I'm going to ask you the same 
question I'll ask the Rust community:


Why are curly braces and semicolons necessary? What information 
do they carry that a compiler could not otherwise reliably obtain?


Here's an example from the D Overview page:


class Foo
{
int foo(Bar c) { return c.bar; }
}

class Bar
{
int bar() { return 3; }
}


Okay, if we remove the curly braces and semicolons, we have:


class Foo

int foo(Bar c) return c.bar


class Bar

int bar() return 3


Would it be difficult to compile the clean version? Would there 
be issues with the design of the lexer/parser? I assume the 
compiler would recognize keywords like return (and a clean syntax 
could drive different rules for what statements and expressions 
could appear on the same line and so forth).


In reality, a compiler would see the above with line ending 
characters terminating every line (e.g. U+000A), so it would be 
as line-aware as a human. I've never built lexers or parsers, 
much less compilers, so maybe I'm missing a major implementation 
hurdle. I'm just thinking that Facebook has built software that 
recognizes my face in other people's pictures, so it seems like 
building software that understands structured text would be a 
solved problem. It puzzles me to see so much apparent punctuation 
noise in a 21st-century language (and, to be fair, Rust puzzles 
me for the same reasons).


JD

[Issue 15988] New: [REG v2.070] Massive Compile Time Slowdown

[via Digitalmars-d-bugs]

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

  Issue ID: 15988
   Summary: [REG v2.070] Massive Compile Time Slowdown
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

According to http://forum.dlang.org/post/yhnfnliteruwixsae...@forum.dlang.org
and http://forum.dlang.org/post/byhninhkueqpscawf...@forum.dlang.org DMD
suffered anywhere between a 47% to 360% increase in compile times.

My largest project actually saw a decrease in compile times, so we have to
solicit the community for examples.

--

Re: Directions to Ibis Hotel in Berlin from Tegel Airport

[Walter Bright via Digitalmars-d]

On 4/26/2016 7:19 PM, Walter Bright wrote:

I'm looking forward to a bratwurst with some good senf!


I got a bratwurst yesterday from a street vendor in front of the 
Brandenburger Tor. Awesome! Made me want to get some lederhosen.


P.S. Also got some Apfel Struedel at the Einstein Cafe on the Unter den 
Linden.

Re: Walter's Famous German Language Essentials Guide

[Walter Bright via Digitalmars-d]

On 5/2/2016 12:09 PM, Iain Buclaw via Digitalmars-d wrote:

For every rule, there are 101 exceptions. :-)

http://shirah-goes-again.blogspot.de/2011/01/entire-english-language-is-big.html


What's the problem? :-)

How can I save a class use the RedBlackTree?

[Dsby via Digitalmars-d-learn]

this is the test Code:


import std.container.rbtree;
import std.stdio;

class TClass
{
int i;
}

void main()
{
RedBlackTree!(TClass) list = new RedBlackTree!(TClass)();
auto t = new TClass();
list.insert(t);
writeln("The rbtree length is ",list.length());
list.removeKey(t);
writeln("The rbtree length is ",list.length());
}

and thisis erro :
/usr/include/dlang/dmd-2.071.0/phobos/std/functional.d-mixin-206(206): Error: 
mutable method object.Object.opCmp is not callable using a inout object
/usr/include/dlang/dmd-2.071.0/phobos/std/container/rbtree.d(871): Error: template instance 
std.functional.binaryFun!("a < b", "a", "b").binaryFun!(inout(TClass), TClass) 
error instantiating
rbtree.d(11):instantiated from here: 
RedBlackTree!(TClass, "a < b", false)

/usr/include/dlang/dmd-2.071.0/phobos/std/functional.d-mixin-206(206): Error: 
function object.Object.opCmp (Object o) is not callable using argument types 
(inout(TClass))
/usr/include/dlang/dmd-2.071.0/phobos/std/container/rbtree.d(873): Error: template instance 
std.functional.binaryFun!("a < b", "a", "b").binaryFun!(TClass, inout(TClass)) 
error instantiating
rbtree.d(11):instantiated from here: 
RedBlackTree!(TClass, "a < b", false)

Re: [OT] Are there any jobs for D?

[Walter Bright via Digitalmars-d]

On 5/2/2016 4:08 PM, Tofu Ninja wrote:

I am going to be graduating soon and figured it would be cool to see if
there were any jobs for D. Where would one look?


This is perfectly on-topic!

D Conference - use twitter #dconf to keep up to date

[Walter Bright via Digitalmars-d-announce]

Jet lagged as I am, I'll be at breakfast at Hotel Ibis at 630am. Come 
and join me!

Can't go to DConf :( Who wants my ticket?

[Lionello Lunesu via Digitalmars-d-announce]

I'm finishing up a big project and can't leave this week. :( Hope to 
tune in remotely though!


Let me know if you're interested or know somebody who is. Or bring that 
skeptical colleague of yours!


Lio.

[Issue 13147] Wrong codegen for thisptr in naked extern (C++) methods

[via Digitalmars-d-bugs]

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

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #4 from safety0ff.bugz  ---
(In reply to Walter Bright from comment #3)
> 
> And you'd be right.
> 
> https://github.com/D-Programming-Language/dmd/pull/4921

Does this fix the struct case as well?

struct S { void foo() { asm { naked; ret; } } }

I just hit this bug.

--

[Issue 15987] New: core.sys.windows.msacm remains pseudo definitions

[via Digitalmars-d-bugs]

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

  Issue ID: 15987
   Summary: core.sys.windows.msacm remains pseudo definitions
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

I found this when verifying the struct sizes for Win32-x64.
Some of the buffer sizes are pseudo values, as its comment says.

I'll send a PR.

--

Re: Setting a list of values

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 6:00 PM, sigod wrote:

On Monday, 2 May 2016 at 10:15:04 UTC, Marc Schütz wrote:

On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote:

[...]


Warning (better: disallowing altogether) about `=>` directly followed
by `{` should be enough to cover all cases. To express that you really
want a lambda returning a lambda, it can be rewritten either as:

(x) => () { assert(x); }

or as:

(x) => ({ assert(x); })

This check can be done purely by looking at the tokens. Should we
someday introduce tuples with `{}`, the check needs to be done after
the node starting with `{` has been parsed to distinguish between
delegate and tuple literals.


It's good idea. I myself stumbled into this before.


Agree.

-Steve

Re: inferred size for static array initialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 4:14 PM, Namespace wrote:


I used it very often, but always assigned the result to an auto-type
variable, never to a slice.


Using auto is fine, but the slice should not happen if you are assigning 
slice to a local var. There is a bug report on this: 
https://issues.dlang.org/show_bug.cgi?id=12625, though it's not as 
focused as I think it should be.


-Steve

Re: relative benefit of .reserve and .length

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 5:57 PM, Eto Demerzel wrote:


For example:

 auto invalid_tokens = uninitializedArray!(string[])(result.failure);
 invalid_tokens.length = 0;

 foreach (index, ref token_result; result.results) {
 if (token_result.error == "NotRegistered") {
 invalid_tokens.assumeSafeAppend() ~= tokens[index];
 }
 else ...
 }

 // use invalid_tokens

It would've been almost perfect code if `assumeSafeAppend` wasn't very
costly. Now I need to declare separate length for `invalid_tokens`, so I
can assign tokens by index. Which I don't like because arrays have
`length` built into them.


Only call assumeSafeAppend when you *remove* data from the array end. 
When you call it on an array that is already appendable, it does 
nothing. Appendable means the array slice ends at the end of the actual 
data.


Better code:

invalid_tokens.length = 0;
invalid_tokens.assumeSafeAppend;

Without seeing your "else", I can't say where else it should be, if at all.

-Steve

Re: [OT] Are there any jobs for D?

[Vladimir Panteleev via Digitalmars-d]

On Monday, 2 May 2016 at 23:15:05 UTC, Brian Schott wrote:

On Monday, 2 May 2016 at 23:08:02 UTC, Tofu Ninja wrote:
I am going to be graduating soon and figured it would be cool 
to see if there were any jobs for D. Where would one look?


http://wiki.dlang.org/Current_D_Use


http://wiki.dlang.org/Jobs

Re: [OT] Are there any jobs for D?

[Brian Schott via Digitalmars-d]

On Monday, 2 May 2016 at 23:08:02 UTC, Tofu Ninja wrote:
I am going to be graduating soon and figured it would be cool 
to see if there were any jobs for D. Where would one look?


http://wiki.dlang.org/Current_D_Use

[OT] Are there any jobs for D?

[Tofu Ninja via Digitalmars-d]

I am going to be graduating soon and figured it would be cool to 
see if there were any jobs for D. Where would one look?

Re: Walter's Famous German Language Essentials Guide

[Jonathan M Davis via Digitalmars-d]

On Mon, 2 May 2016 21:09:41 +0200
Iain Buclaw via Digitalmars-d  wrote:

> On 2 May 2016 at 14:55, Russel Winder via Digitalmars-d
>  wrote:
> > On Mon, 2016-05-02 at 12:18 +, Claude via Digitalmars-d wrote:
> > […]
> >>
> >> In french, there are 2 specials cases about gender. "orgue"
> >> (organ) and "amour" (love) are masculine on singular, and
> >> feminine on plural.
> >
> > Oh FFS. And they say English is a difficult language.
> >
>
> For every rule, there are 101 exceptions. :-)
>
> http://shirah-goes-again.blogspot.de/2011/01/entire-english-language-is-big.html

LoL. That's hilarious - a tad long to read though, especially since it's
practically just a long list of words.

- Jonathan M Davis

[Issue 15985] [REG2.068/2.069] Code doesn't link unless compiled with -debug

[via Digitalmars-d-bugs]

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

j...@red.email.ne.jp changed:

   What|Removed |Added

 CC||j...@red.email.ne.jp

--- Comment #1 from j...@red.email.ne.jp ---
I confirmed this with dmd 2.068 and -m64 mode in Windows.

So -allinst option works.

--

Re: Setting a list of values

[sigod via Digitalmars-d-learn]

On Monday, 2 May 2016 at 10:15:04 UTC, Marc Schütz wrote:

On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote:

[...]


Warning (better: disallowing altogether) about `=>` directly 
followed by `{` should be enough to cover all cases. To express 
that you really want a lambda returning a lambda, it can be 
rewritten either as:


(x) => () { assert(x); }

or as:

(x) => ({ assert(x); })

This check can be done purely by looking at the tokens. Should 
we someday introduce tuples with `{}`, the check needs to be 
done after the node starting with `{` has been parsed to 
distinguish between delegate and tuple literals.


It's good idea. I myself stumbled into this before.

Re: Threads

[safety0ff via Digitalmars-d]

On Monday, 2 May 2016 at 16:39:13 UTC, vino wrote:

Hi All,

 I am a newbie for D programming and need some help, I am 
trying to write a program using the example given in the book 
The "D Programming Language" written by "Andrei Alexandrescu"


Make sure to check the errata on his site: 
http://erdani.com/index.php?cID=109



Page: 406 Print: 1
Current text:
foreach (immutable(ubyte)[] buffer; 
stdin.byChunk(bufferSize)) send(tid, buffer);

Correction:
foreach (buffer; stdin.byChunk(bufferSize)) send(tid, 
buffer.idup)

Re: Walter's Famous German Language Essentials Guide

[H. S. Teoh via Digitalmars-d]

On Mon, May 02, 2016 at 06:22:49PM +0200, Jonathan M Davis via Digitalmars-d 
wrote:
[...]
> In any case, learning any new language is hard - especially the
> farther it is from your own (e.g. Asian languages are going to
> generally be pretty brutal to learn for someone speaking a European
> languages).

Every language is trivial to a native speaker.

As for which languages are brutal or trivial to an L2 learner, that
depends on whether the target language makes distinctions that aren't
present in one's native tongue.

Now, "Asian languages" as a category doesn't make very much sense,
because it encompasses far too wide a scope to be a useful category. You
have language isolates like Japanese and Korean, with rather distinctive
grammars, then the numerous Chinese "dialects" (which are properly
languages in their own right), which are part of the wider Sino-Tibetan
languages (including things like Vietnamese, Burmese, possibly Thai,
among others), the Austronesian languages, and a whole variety of
others, that have basically no resemblance with each other.

As far as the Chinese languages are concerned, one common difficulty for
foreign language learners is the tonal distinctions, which are basically
absent from European languages. Hence, a word like "ma" can mean a whole
variety of different things depending on its pitch contour, but the
problem is your typical European language speaker can't even *hear* the
difference to begin with, so it sounds almost like pulling magical
bunnies out of the air. (Some of the Chinese "dialects" sport up to 9
distinct tones -- L2 learners have enough trouble telling the 4 tones of
standard Mandarin apart, let alone the fine distinctions between 9!)
However, grammar-wise, the Chinese languages are far simpler than the
European languages; so once you get over the tonal hump, it's actually a
lot easier to learn than, say, English or French. Or Russian.

Of course, the other great difficulty is the writing system, which
requires the memorization of between 1000-2000 different glyphs just to
be able to read with some fluency.  But hey, that beats learning
Japanese, which has *three* different writing systems, all of which you
must master in order to be able to read at all!

Austronesian languages, by contrast, are almost trivial in terms of
pronunciation, and for the most part have adopted the Latin alphabet, so
reading and writing isn't hampered by the need to learn a whole new
writing system. However, the grammar, while not exactly as complex as,
say, Russian or Greek, significantly diverges from the way grammar
usually works in European languages, so some amount of effort is
required in order to get it right.

Japanese and Korean appear to be language isolates, and their respective
grammars are quite unique. Korean writing is relatively easy to master
-- it's phonetic, like the Latin alphabet, just composed differently --
but Japanese requires mastery of 3 different writing systems. Both
languages also sport a system of honorifics that mostly doesn't exist in
European languages, and may be difficult for an L2 learner to pick up --
addressing somebody with the wrong honorifics can sound extremely
insulting or needlessly polite.


On Mon, May 02, 2016 at 07:40:29PM +, Meta via Digitalmars-d wrote:
[...]
> Many Asian languages are much more straightforward then any of the
> romance languages. In Chinese verbs aren't even inflected for tense,
> voice, etc., much less this silly gendered noun stuff. It's extremely
> refreshing and quite simple grammatically.

Yes, though the tonal system and the writing system are two things that
usually discourage many foreign learners from even trying.



On Mon, May 02, 2016 at 08:33:47PM +, tsbockman via Digitalmars-d wrote:
> On Monday, 2 May 2016 at 19:09:41 UTC, Iain Buclaw wrote:
> >For every rule, there are 101 exceptions. :-)
> >
> >http://shirah-goes-again.blogspot.de/2011/01/entire-english-language-is-big.html
> 
> As an educated native English speaker, I must say that poem is
> horrifying.
> 
> Clearly, spelling reform is urgently needed:
> http://www.ashvital.freeservers.com/ze_dream.htm

Spelling reforms have a spotty history... Spanish had one relatively
recently (i.e., within the last few hundred years), and is therefore
much easier to read today than back then.  Russian had a major overhaul
in 1917, which dropped a large number of silent vowels and redundant
consonants, so today Russian is also relatively easy to read once you
master the Cyrillic alphabet. (And so the story goes, this reform saved
millions of dollars (rubles?) in printing and paper costs, due to the
elimination of said silent vowels which were present at the end of
almost every word in the old spelling.) French and English are both
overdue for reform, though, their respective spelling rules having been
codified about a half millenium ago, and between then and now
pronunciation has changed so drastically that, as the above poem shows,
the current 

Re: relative benefit of .reserve and .length

[Eto Demerzel via Digitalmars-d-learn]

On Monday, 2 May 2016 at 14:47:01 UTC, Steven Schveighoffer wrote:

On 4/29/16 6:10 AM, sigod wrote:
On Thursday, 28 April 2016 at 14:08:26 UTC, Steven 
Schveighoffer wrote:

On 4/28/16 8:56 AM, Jay Norwood wrote:

[...]


.reserve should make an improvement for large amount of 
appending,

since you pre-allocate the data.

[...]


How about `assumeSafeAppend`? Does it have any positive impact 
on

performance?


I don't know why you would call it. assumeSafeAppend is an 
expensive no-op if you have appendable array.


-Steve


For example:

	auto invalid_tokens = 
uninitializedArray!(string[])(result.failure);

invalid_tokens.length = 0;

foreach (index, ref token_result; result.results) {
if (token_result.error == "NotRegistered") {
invalid_tokens.assumeSafeAppend() ~= tokens[index];
}
else ...
}

// use invalid_tokens

It would've been almost perfect code if `assumeSafeAppend` wasn't 
very costly. Now I need to declare separate length for 
`invalid_tokens`, so I can assign tokens by index. Which I don't 
like because arrays have `length` built into them.

[Issue 15984] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

--- Comment #5 from Stewart Gordon  ---
(In reply to Denis Shelomovskij from comment #4)
> Thanks, I still can't remember how does current implementation of D
> contracts work.

It looks like it calls the base class's in contract and, if that fails, calls
the derived class's in contract?

>> But even better would be to add debugging output to I's in contract.
> 
> Parameter contains garbage, I don't think there is any need to print it.

How do you establish that the parameter contains garbage (as opposed to any
other possible cause of what we're observing) without printing it?

--

[Issue 15986] New: [std.experimental.allocator.mallocator] calloc?

[via Digitalmars-d-bugs]

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

  Issue ID: 15986
   Summary: [std.experimental.allocator.mallocator] calloc?
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/phobos/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jv_vor...@msn.com

There's no implementation for a cleared allocation (calloc). Why is that?

--

Re: Discrete semantics of lambda expressions

[Timon Gehr via Digitalmars-d]

On 02.05.2016 22:20, Adam D. Ruppe wrote:

On Monday, 2 May 2016 at 20:11:53 UTC, Timon Gehr wrote:

I don't think { ... } as shorthand for (){ ... } is necessary or
particularly useful in the first place.


Indeed. I don't think =>x as a shorthand for {return x;} is really worth
it either... D has a ridiculous number of variations on function syntax.
...


function int delegate()delegate(int)(int y){ return (x)const=>{ return 
x+y;}; }; // :o)


(=>x is not valid.)


But I don't expect any of them to be removed either.


Most of them don't hurt much (unlike { ... }). It's quite annoying that 
function definition syntax and delegate literal syntax are inconsistent 
though. E.g. lambda syntax should be usable for named functions (int 
x()=>3;).

Re: Walter's Famous German Language Essentials Guide

[tsbockman via Digitalmars-d]

On Monday, 2 May 2016 at 19:09:41 UTC, Iain Buclaw wrote:

For every rule, there are 101 exceptions. :-)

http://shirah-goes-again.blogspot.de/2011/01/entire-english-language-is-big.html


As an educated native English speaker, I must say that poem is 
horrifying.


Clearly, spelling reform is urgently needed:
http://www.ashvital.freeservers.com/ze_dream.htm

Re: Discrete semantics of lambda expressions

[Adam D. Ruppe via Digitalmars-d]

On Monday, 2 May 2016 at 20:11:53 UTC, Timon Gehr wrote:
I don't think { ... } as shorthand for (){ ... } is necessary 
or particularly useful in the first place.


Indeed. I don't think =>x as a shorthand for {return x;} is 
really worth it either... D has a ridiculous number of variations 
on function syntax.


But I don't expect any of them to be removed either.

[Issue 314] [module] Static, renamed, and selective imports are always public

[via Digitalmars-d-bugs]

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

--- Comment #57 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3d37aee77d12e13b970a84d3e06101e5fd04a00c
Byte Order Mark (BOM) handling functions rewrite

* move to std.encoding
* less overengineering

https://github.com/D-Programming-Language/phobos/pull/3870 rework

Don't use top-level selective import in std.math because of DMD issue 314.

some quickfur comments

whitespace

remove used import

steven suggestion

utfBom

andrei nitpicks

andrei null

--

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

On Monday, 2 May 2016 at 20:05:15 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:38 PM, Namespace wrote:
The assembler might be safe in some instances, but that 
doesn't
reflect the original internal representation in the compiler. 
Some
other configuration of calls may allow the compiler to reuse 
that

memory, and then you run into problems.

I'm wondering if you used my rewrite if it would actually 
output the

same thing?


Not quite. Look for yourself:
https://godbolt.org/g/kO8hdW
https://godbolt.org/g/KCfYPy


Except for offsets, it looks identical. May be the compiler 
puts things in different spots for different ways of writing.


But the thing that's not disclosed here is: what happens when 
the compiler feels the need to reuse that stack space? Your 
example doesn't have anything that may compete for the space, 
it just returns after this is over.


For example, define a static array of exactly the same size to 
use after the call:


int[3] x;

Now, see if x is pigeonholed into that same place your 
temporary return existed (and therefore 'as' points at it).


I'm still fully on the side of this being unsafe.

-Steve


I used it very often, but always assigned the result to an 
auto-type variable, never to a slice.

Re: inferred size for static array initialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 3:38 PM, Namespace wrote:

The assembler might be safe in some instances, but that doesn't
reflect the original internal representation in the compiler. Some
other configuration of calls may allow the compiler to reuse that
memory, and then you run into problems.

I'm wondering if you used my rewrite if it would actually output the
same thing?


Not quite. Look for yourself:
https://godbolt.org/g/kO8hdW
https://godbolt.org/g/KCfYPy


Except for offsets, it looks identical. May be the compiler puts things 
in different spots for different ways of writing.


But the thing that's not disclosed here is: what happens when the 
compiler feels the need to reuse that stack space? Your example doesn't 
have anything that may compete for the space, it just returns after this 
is over.


For example, define a static array of exactly the same size to use after 
the call:


int[3] x;

Now, see if x is pigeonholed into that same place your temporary return 
existed (and therefore 'as' points at it).


I'm still fully on the side of this being unsafe.

-Steve

Re: Discrete semantics of lambda expressions

[Timon Gehr via Digitalmars-d]

On 02.05.2016 19:31, Adam D. Ruppe wrote:

On Monday, 2 May 2016 at 15:52:34 UTC, Xinok wrote:

I'm proposing that we add a warning to the compiler for this
particular case. If the programmer intended to return a lambda, then
rewrite the expression as one of:


I agree, forcing people to rewrite it is a good idea.


I don't think { ... } as shorthand for (){ ... } is necessary or 
particularly useful in the first place.

Re: Walter's Famous German Language Essentials Guide

[Meta via Digitalmars-d]

On Monday, 2 May 2016 at 16:22:49 UTC, Jonathan M Davis wrote:

On Mon, 02 May 2016 13:55:35 +0100
Russel Winder via Digitalmars-d  
wrote:


On Mon, 2016-05-02 at 12:18 +, Claude via Digitalmars-d 
wrote: […]

> [...]

Oh FFS. And they say English is a difficult language.


LOL. Well, every language has its quirks - especially with the 
commonly used words (they probably get munged the most over 
time, because they get used the most), but I've found that 
French is far more consistent than English - especially when 
get a grammar book that actually explains things rather than 
just telling you what to do. English suffers from having a lot 
of different sources for its various words. It's consistent in 
a lot of ways, but it's a huge mess in others - though I for 
one think that the fact that English has no gender like 
languages such as French and German is a huge win.


In any case, learning any new language is hard - especially the 
farther it is from your own (e.g. Asian languages are going to 
generally be pretty brutal to learn for someone speaking a 
European languages).


- Jonathan M Davis


Many Asian languages are much more straightforward then any of 
the romance languages. In Chinese verbs aren't even inflected for 
tense, voice, etc., much less this silly gendered noun stuff. 
It's extremely refreshing and quite simple grammatically.

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

The assembler might be safe in some instances, but that doesn't 
reflect the original internal representation in the compiler. 
Some other configuration of calls may allow the compiler to 
reuse that memory, and then you run into problems.


I'm wondering if you used my rewrite if it would actually 
output the same thing?


Not quite. Look for yourself:
https://godbolt.org/g/kO8hdW
https://godbolt.org/g/KCfYPy

Re: Inheritance of mixin

[tsbockman via Digitalmars-d]

On Monday, 2 May 2016 at 18:14:29 UTC, Basile B. wrote:

On Monday, 2 May 2016 at 17:50:50 UTC, tsbockman wrote:

[...]

That's not how it works currently, but there is no technical 
reason it couldn't be *made* to work that way.


Obviously this would be a breaking change though; `this T` 
template methods that should retain the current behaviour 
could be marked `final`. (Given that non-template methods are 
virtual by default, I think requiring template methods to be 
marked `final` would improve code clarity, anyway.)


Not that much a breaking change. Perhaps a slight decrease of 
the performances...and even not indeed: in all the previous 
usages devirtualization of the will be possible.


It's a significant breaking change, because the purpose of it is 
to change the output of Andrew Benton's earlier example:


void main() {
Base a = new Base(), b = new Inheritor();
a.writeName.writeln;
b.writeName.writeln; // The semantics of this line changes.
}

Currently, the above will call the `Base` version of 
`writeName()` for `b`. With my proposal, it would call the 
`Inheritor()` version.

Re: My favourite game: DMD guess the error reason.

[Iain Buclaw via Digitalmars-d]

On Monday, 2 May 2016 at 19:14:59 UTC, Steven Schveighoffer wrote:

On 5/2/16 2:25 PM, Iain Buclaw wrote:
On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer 
wrote:

On 5/2/16 3:13 AM, Iain Buclaw wrote:

[2]: The ptrdiff_t and size_t types have a different size.


Wow, it would be a copy-paste error of some sort? An 
interesting
possibility. But I'm going to say no, I don't see how this 
comes into

play for the template constraints.



While there may be an alias in object.d, I'd say it's purpose 
is purely
cosmetic (and to prevent missing symbol errors).  It is the 
compiler
that decides what types size_t, ptrdiff_t have.  And while 
there are
targets where word and pointer sizes are different, GDC does 
not honour
this however, as the D specification on these types (and 
D_LP64) trumps

that.


So you are saying that:

int * p;
int[] arr;
assert(typeof(p - p).sizeof == typeof(arr.length).sizeof);

could fail regardless of how object.d defines size_t and 
ptrdiff_t? I can't imagine much would work. Interesting note 
though.


I've worked with processors that have different word and 
pointer sizes, but they were all too weak to be able to use D 
(if you used betterc switch maybe).




Yes, although I'm not aware of LDC doing this.  I can say that 
GDC will always pick int/uint or long/ulong.  Maybe at some point 
I should allow short/ushort for 16bit targets.


--
Iain

Re: inferred size for static array initialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 3:12 PM, Namespace wrote:

On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:02 PM, Namespace wrote:

On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:

A slice of a no-longer-existing temporary! Admittedly, this is not an
issue with your code, but a deeper issue of allowing slicing of
rvalues.

This works:

int[] as = [1, 2, 3].s;
writeln(as[2]);


Of course this slice is only valid as long as you dont leave the scope.
That's maybe what you tried to say, right?


No, because 'as' is pointing at stack space no longer allocated. It
may work, and it may not, but having it work is not proof that it's
sound.

To make things clear, this is what your code effectively does:

int[] as = void;
{
   auto _tmp = [1, 2, 3].s;
   as = _tmp;
}

Which is not the same thing as having the static array a defined stack
variable in the same scope.



The assembler looks different than that but I may be wrong and I only
looked at gdc.
But anyway, that means with 'pragma(inline, true)' I'm save. Is that right?


The assembler might be safe in some instances, but that doesn't reflect 
the original internal representation in the compiler. Some other 
configuration of calls may allow the compiler to reuse that memory, and 
then you run into problems.


I'm wondering if you used my rewrite if it would actually output the 
same thing?


But in any case, I don't know the answer to the pragma(inline) thing. I 
would guess it is subject to the same issues, but I'm not 100% sure.


-Steve

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:02 PM, Namespace wrote:

On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this 
is not an
issue with your code, but a deeper issue of allowing slicing 
of rvalues.

This works:

int[] as = [1, 2, 3].s;
writeln(as[2]);


Of course this slice is only valid as long as you dont leave 
the scope.

That's maybe what you tried to say, right?


No, because 'as' is pointing at stack space no longer 
allocated. It may work, and it may not, but having it work is 
not proof that it's sound.


To make things clear, this is what your code effectively does:

int[] as = void;
{
   auto _tmp = [1, 2, 3].s;
   as = _tmp;
}

Which is not the same thing as having the static array a 
defined stack variable in the same scope.


-Steve


The assembler looks different than that but I may be wrong and I 
only looked at gdc.
But anyway, that means with 'pragma(inline, true)' I'm save. Is 
that right?

Re: My favourite game: DMD guess the error reason.

[Steven Schveighoffer via Digitalmars-d]

On 5/2/16 2:25 PM, Iain Buclaw wrote:

On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:13 AM, Iain Buclaw wrote:

[2]: The ptrdiff_t and size_t types have a different size.


Wow, it would be a copy-paste error of some sort? An interesting
possibility. But I'm going to say no, I don't see how this comes into
play for the template constraints.



While there may be an alias in object.d, I'd say it's purpose is purely
cosmetic (and to prevent missing symbol errors).  It is the compiler
that decides what types size_t, ptrdiff_t have.  And while there are
targets where word and pointer sizes are different, GDC does not honour
this however, as the D specification on these types (and D_LP64) trumps
that.


So you are saying that:

int * p;
int[] arr;
assert(typeof(p - p).sizeof == typeof(arr.length).sizeof);

could fail regardless of how object.d defines size_t and ptrdiff_t? I 
can't imagine much would work. Interesting note though.


I've worked with processors that have different word and pointer sizes, 
but they were all too weak to be able to use D (if you used betterc 
switch maybe).


-Steve

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

[via Digitalmars-d-bugs]

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

--- Comment #10 from sigod  ---
(In reply to Jack Stouffer from comment #9)
> (In reply to sigod from comment #8)
> > I'm not betting on anything. It was a figure of speech.
> 
> The best way to call someone's bluff is to put money on the table. If you
> were sure that no one was using this for duplication, then you would have
> taken my bet.

I don't gamble. Especially when it's impossible to win.

(Let's end off-topic here.)

--

Re: inferred size for static array initialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 3:02 PM, Namespace wrote:

On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:

A slice of a no-longer-existing temporary! Admittedly, this is not an
issue with your code, but a deeper issue of allowing slicing of rvalues.

This works:

int[] as = [1, 2, 3].s;
writeln(as[2]);


Of course this slice is only valid as long as you dont leave the scope.
That's maybe what you tried to say, right?


No, because 'as' is pointing at stack space no longer allocated. It may 
work, and it may not, but having it work is not proof that it's sound.


To make things clear, this is what your code effectively does:

int[] as = void;
{
   auto _tmp = [1, 2, 3].s;
   as = _tmp;
}

Which is not the same thing as having the static array a defined stack 
variable in the same scope.


-Steve

Re: Beta release DUB 0.9.25-beta.3

[Sönke Ludwig via Digitalmars-d-announce]

Am 02.05.2016 um 19:03 schrieb Suliman:

On Monday, 2 May 2016 at 12:51:04 UTC, Sönke Ludwig wrote:

Contains fixes for multiple issues resulting in "missing non-optional
dependency" errors.

Download at http://code.dlang.org/download ("latest preview")

Beta-2 thread:
https://forum.dlang.org/thread/nfpntb$kbl$1...@digitalmars.com


An chance that 1.0 will be included in dmd distrib?


Yes, that's the plan!

Re: Walter's Famous German Language Essentials Guide

[Iain Buclaw via Digitalmars-d]

On 2 May 2016 at 14:55, Russel Winder via Digitalmars-d
 wrote:
> On Mon, 2016-05-02 at 12:18 +, Claude via Digitalmars-d wrote:
> […]
>>
>> In french, there are 2 specials cases about gender. "orgue"
>> (organ) and "amour" (love) are masculine on singular, and
>> feminine on plural.
>
> Oh FFS. And they say English is a difficult language.
>

For every rule, there are 101 exceptions. :-)

http://shirah-goes-again.blogspot.de/2011/01/entire-english-language-is-big.html

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

A slice of a no-longer-existing temporary! Admittedly, this is 
not an issue with your code, but a deeper issue of allowing 
slicing of rvalues.

This works:

int[] as = [1, 2, 3].s;
writeln(as[2]);

Bug or feature? Or did I may misunderstood you?

You can drop auto. It's just a placeholder for the storage 
class in the case where a storage class isn't specified.

Right, I forgot, it's a bit since I wrote something in D.

Re: constructed variadic call

[Stefan Koch via Digitalmars-d-learn]

On Monday, 2 May 2016 at 18:22:52 UTC, Erik Smith wrote:
Is there way to construct an "argument pack" from a non-static 
array (like the switch below)?  I need to transport a variadic 
call through a void*.


switch (a.length) {
  case 1: foo(a[1]); break;
  case 2: foo(a[1], a[2]); break;
  case 3: foo(a[1], a[2], a[3]); break;
...
}


Yes there is.
Using a string mixin.

Re: Method doesn't compile when defined in a mixin, but is fine without?

[Stefan Koch via Digitalmars-d-learn]

On Sunday, 1 May 2016 at 14:01:51 UTC, pineapple wrote:

On Sunday, 1 May 2016 at 13:46:14 UTC, ag0aep6g wrote:

On 01.05.2016 15:32, pineapple wrote:
static string vectorpropertymixin(string name, string 
SDL_getter, string

SDL_setter){

[...]

mixin(vectorpropertymixin(
 "minsize", "SDL_GetWindowMinimumSize", 
"SDL_GetWindowMinimumSize"

));


Should the second one be "SDL_SetWindowMinimumSize" here? 
("Set" instead of "Get".)


See, of course it was going to be something stupid like that. 
Would be nice if compile errors were kinder to mixins, might've 
realized where the error actually was. Any tips on that?


Write code into a file or wait for my ctfe-debug tool.

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this is 
not an issue with your code, but a deeper issue of allowing 
slicing of rvalues.

This works:

int[] as = [1, 2, 3].s;
writeln(as[2]);


Of course this slice is only valid as long as you dont leave the 
scope. That's maybe what you tried to say, right?

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

[via Digitalmars-d-bugs]

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

--- Comment #9 from Jack Stouffer  ---
(In reply to sigod from comment #8)
> I'm not betting on anything. It was a figure of speech.

The best way to call someone's bluff is to put money on the table. If you were
sure that no one was using this for duplication, then you would have taken my
bet.

--

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

[via Digitalmars-d-bugs]

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

--- Comment #8 from sigod  ---
I'm not betting on anything. It was a figure of speech.

--

Re: My favourite game: DMD guess the error reason.

[Iain Buclaw via Digitalmars-d]

On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:13 AM, Iain Buclaw wrote:

[2]: The ptrdiff_t and size_t types have a different size.


Wow, it would be a copy-paste error of some sort? An 
interesting possibility. But I'm going to say no, I don't see 
how this comes into play for the template constraints.




While there may be an alias in object.d, I'd say it's purpose is 
purely cosmetic (and to prevent missing symbol errors).  It is 
the compiler that decides what types size_t, ptrdiff_t have.  And 
while there are targets where word and pointer sizes are 
different, GDC does not honour this however, as the D 
specification on these types (and D_LP64) trumps that.


--
Iain

constructed variadic call

[Erik Smith via Digitalmars-d-learn]

Is there way to construct an "argument pack" from a non-static 
array (like the switch below)?  I need to transport a variadic 
call through a void*.


switch (a.length) {
  case 1: foo(a[1]); break;
  case 2: foo(a[1], a[2]); break;
  case 3: foo(a[1], a[2], a[3]); break;
...
}

Re: Inheritance of mixin

[Basile B. via Digitalmars-d]

On Monday, 2 May 2016 at 17:50:50 UTC, tsbockman wrote:

On Monday, 2 May 2016 at 17:37:14 UTC, Basile B. wrote:
templatized functions in classes will never be virtual and 
there's a technical reason explained here:


https://issues.dlang.org/show_bug.cgi?id=1657#c1

(TL;DR: it's problematic to generate the vtbl)


[...]

That's not how it works currently, but there is no technical 
reason it couldn't be *made* to work that way.


Obviously this would be a breaking change though; `this T` 
template methods that should retain the current behaviour could 
be marked `final`. (Given that non-template methods are virtual 
by default, I think requiring template methods to be marked 
`final` would improve code clarity, anyway.)


Not that much a breaking change. Perhaps a slight decrease of the 
performances...and even not indeed: in all the previous usages 
devirtualization of the will be possible.

Re: inferred size for static array initialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/2/16 1:43 PM, Namespace wrote:

On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:

Is there a way to initialize a static array and have it's size
inferred (and that works for arrays of structs using braced
literals)?  This would make it easier to maintain longer static array
definitions.  The code below doesn't work when removing the array size
even though the array is declared as static immutable.

import std.traits;
static immutable int[] a  = [1,2,3];
static assert(isStaticArray!(typeof(a)));  // fails


I still like

auto s(T, size_t n)(T[n] arr) {
 return arr;
}


Interesting. But there is a major problem here...



auto arr = [1, 2, 3].s;


But of course this won't work:

int[] a  = [1,2,3].s;
static assert(isStaticArray!(typeof(a)));  // fails



And this is the problem.


Since 'a' is just a slice.


A slice of a no-longer-existing temporary! Admittedly, this is not an 
issue with your code, but a deeper issue of allowing slicing of rvalues.




But this will work:

immutable auto a  = [1,2,3].s;



You can drop auto. It's just a placeholder for the storage class in the 
case where a storage class isn't specified.


-Steve

Re: My favourite game: DMD guess the error reason.

[Iain Buclaw via Digitalmars-d]

On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:

On 5/2/16 3:13 AM, Iain Buclaw wrote:

[5]: The template function core.varargs.va_arg does not exist.


haha!



You may laugh, but while almost all of these answers listed are 
complete fantasy, a few listed did finally surface after I found 
out and stubbed what was causing this exact error when building 
about a third of all modules in phobos.


Also. Yes it is very possible for druntime to compile and pass 
the unittester without you noticing a problem such as this, as 
only std.format uses the va_arg function that accepts a TypeInfo 
parameter. (and there are no unittests in core.varargs :-)


--
Iain

Re: Inheritance of mixin

[tsbockman via Digitalmars-d]

On Monday, 2 May 2016 at 17:37:14 UTC, Basile B. wrote:
templatized functions in classes will never be virtual and 
there's a technical reason explained here:


https://issues.dlang.org/show_bug.cgi?id=1657#c1

(TL;DR: it's problematic to generate the vtbl)


I understand why template methods in general shouldn't be 
virtual. `this T` is special though, and a method with no other 
template parameters could be lowered to an ordinary virtual 
method in a straightforward fashion.


Basically, this:

class A
{
string foo(this T)() { return T.stringof; }
}

class B : A { }

Could be lowered to this:

class A
{
string foo() { return A.stringof; }
}

class B : A
{
override string foo() { return B.stringof; }
}

That's not how it works currently, but there is no technical 
reason it couldn't be *made* to work that way.


Obviously this would be a breaking change though; `this T` 
template methods that should retain the current behaviour could 
be marked `final`. (Given that non-template methods are virtual 
by default, I think requiring template methods to be marked 
`final` would improve code clarity, anyway.)

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #7 from Jack Stouffer  ---
(In reply to sigod from comment #4)
> I bet no one uses `array()` for duplicating
> arrays.

Maybe, maybe not. But I'd bet $500 that people rely on the functionality and
don't know it. If this is changed you'll have people suddenly wondering why
their arrays are getting filled garbage data.

With a function as popular as std.array.array, I'd say this change is way too
dangerous.

--

Re: inferred size for static array initialization

[Namespace via Digitalmars-d-learn]

On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size 
inferred (and that works for arrays of structs using braced 
literals)?  This would make it easier to maintain longer static 
array definitions.  The code below doesn't work when removing 
the array size even though the array is declared as static 
immutable.


import std.traits;
static immutable int[] a  = [1,2,3];
static assert(isStaticArray!(typeof(a)));  // fails


I still like

auto s(T, size_t n)(T[n] arr) {
return arr;
}

auto arr = [1, 2, 3].s;


But of course this won't work:

int[] a  = [1,2,3].s;
static assert(isStaticArray!(typeof(a)));  // fails


Since 'a' is just a slice.

But this will work:

immutable auto a  = [1,2,3].s;

Re: Inheritance of mixin

[Basile B. via Digitalmars-d]

On Monday, 2 May 2016 at 16:41:01 UTC, tsbockman wrote:

On Saturday, 30 April 2016 at 01:06:18 UTC, Andrew Benton wrote:
Additionally, any libraries that provide a base class with a 
mixin require inheritors to know about that mixin and provide 
it in their own code.  It certainly isn't going to happen in 
every case, but if the needed functionality is provided by 
mixins, then users of the library could have problems.


I spent a while trying to figure out how to automatically 
verify that a mixin required by a class hierarchy is included 
in all derived classes, and failed to come up with a general 
purpose solution. (I found a partial solution involving a `this 
T` templatized constructor, but it had a lot of problems.) So, 
I agree now that this is a problem worth solving.


It could be fixed by extending template mixins as you and 
others have proposed.


Another possible solution would be to fix `this T` template 
functions to be virtual, and automatically generate an override 
for each derived class. This would directly solve the most 
common use case, and also provide an (awkward) way to 
automatically verify mixin inclusion in derived classes for 
more complex scenarios.


templatized functions in classes will never be virtual and 
there's a technical reason explained here:


https://issues.dlang.org/show_bug.cgi?id=1657#c1

(TL;DR: it's problematic to generate the vtbl)

In some cases, remixing a template in each sub classes works (for 
example here https://github.com/Mihail-K/witchcraft#caveats), in 
some cases a template with a template this parameter works but 
**here** it's true that among the workarounds,  none is conform 
with the OOP principles as noted in this answer: 
https://forum.dlang.org/post/pacfkkgazpqaodsbq...@forum.dlang.org.

Re: Discrete semantics of lambda expressions

[Adam D. Ruppe via Digitalmars-d]

On Monday, 2 May 2016 at 15:52:34 UTC, Xinok wrote:
I'm proposing that we add a warning to the compiler for this 
particular case. If the programmer intended to return a lambda, 
then rewrite the expression as one of:


I agree, forcing people to rewrite it is a good idea.

Re: inferred size for static array initialization

[Erik Smith via Digitalmars-d-learn]

I tried to combine the two solutions (Basile with the wrapper, 
Marco with the struct initializer support) but it didn't work. 
The struct initializer is not a array literal (seems obvious 
now).   I might go with the 2nd but it's pretty heavy just to get 
the size.


Thanks.


struct S {
int a, b;
}

auto toStaticArray(alias array)()
{
struct S { int a, b; }

immutable tab = {
static enum S[] s = array;
return cast(typeof(s[0])[s.length])s;
}();
return tab;
}

enum a = toStaticArray!([{1,2},{3,4}]);  // error

Re: inferred size for static array initialization

[Marco Leise via Digitalmars-d-learn]

Am Mon, 2 May 2016 18:52:11 +0200
schrieb ag0aep6g :

> On 02.05.2016 15:53, Marco Leise wrote:
> >immutable tab = { static enum S[] s = [  
> 
> `static enum`? What kind of black magic is this?

I don't know, but it works, haha.

-- 
Marco

Re: Release D 2.071.0

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 2 May 2016 at 16:47:13 UTC, Márcio Martins wrote:

with 2.070.2:
real0m9.775s
user0m9.036s
sys 0m0.700s

with 2.071.0:
real0m45.011s
user0m41.760s
sys 0m3.144s


Wow, that's pretty awful.

Have you tried using digger to find out what caused the slow down?

Re: Beta release DUB 0.9.25-beta.3

[Suliman via Digitalmars-d-announce]

On Monday, 2 May 2016 at 12:51:04 UTC, Sönke Ludwig wrote:
Contains fixes for multiple issues resulting in "missing 
non-optional dependency" errors.


Download at http://code.dlang.org/download ("latest preview")

Beta-2 thread: 
https://forum.dlang.org/thread/nfpntb$kbl$1...@digitalmars.com


An chance that 1.0 will be included in dmd distrib?

Re: inferred size for static array initialization

[ag0aep6g via Digitalmars-d-learn]

On 02.05.2016 15:53, Marco Leise wrote:

   immutable tab = { static enum S[] s = [


`static enum`? What kind of black magic is this?

[Issue 15985] New: [REG2.068/2.069] Code doesn't link unless compiled with -debug

[via Digitalmars-d-bugs]

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

  Issue ID: 15985
   Summary: [REG2.068/2.069] Code doesn't link unless compiled
with -debug
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: link-failure
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

/// test.d ///
struct S()
{
void delegate() d;
}

S!() f_Ds(U=D*)()
{
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

static if (is(U V : V*))
return f_Ds!V();
}

void f_E()()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D* d;
}

struct B
{
}

struct C
{
A a;
B b;
}

struct D
{
C c;
}

void main()
{
f_E();
f_Ds!D();
}
//

Linux  , DMD 2.068.0, with-debug: OK
Linux  , DMD 2.068.0, without -debug: OK
Linux  , DMD 2.069.0, with-debug: OK
Linux  , DMD 2.069.0, without -debug: Link error

Windows, DMD 2.067.0, with-debug: OK
Windows, DMD 2.067.0, without -debug: OK
Windows, DMD 2.068.0, with-debug: OK
Windows, DMD 2.068.0, without -debug: Link error

Bisection attempts point towards master/stable branch merges (i.e. nothing
useful).

It is probably a latent heisenbug triggered by other changes.

Downstream issue: https://github.com/CyberShadow/Digger/issues/36

--

Re: Threads

[Alex Parrill via Digitalmars-d]

On Monday, 2 May 2016 at 16:39:13 UTC, vino wrote:

Hi All,

 I am a newbie for D programming and need some help, I am 
trying to write a program using the example given in the book 
The "D Programming Language" written by "Andrei Alexandrescu" 
with few changes such as the example program read the input 
from stdin and prints the data to stdout, but my program reads 
the input from the file(readfile.txt) and writes the output to 
another file(writefile.txt), and I am getting the below errors 
while compiling


Error:

[root@localhost DProjects]# dmd readwriteb.d
readwriteb.d(7): Error: cannot implicitly convert expression 
(__aggr2859.front()) of type ubyte[] to immutable(ubyte)[]
readwriteb.d(15): Error: cannot implicitly convert expression 
(receiveOnly()) of type immutable(ubyte)[] to 
std.outbuffer.OutBuffer

[root@localhost DProjects]#

Version: DMD64 D Compiler v2.071.0

Code:

import std.algorithm, std.concurrency, std.stdio, 
std.outbuffer, std.file;


void main() {
   enum bufferSize = 1024 * 100;
   auto file = File("readfile.txt", "r");
   auto tid = spawn();
   foreach (immutable(ubyte)[] buffer; 
file.byChunk(bufferSize)) {

  send(tid, buffer);
   }
}

void fileWriter() {
   auto wbuf  = new OutBuffer();
   for (;;) {
  wbuf = receiveOnly!(immutable(ubyte)[])();
  write("writefile.txt", wbuf);
   }
}

From,
Vino.B


File.byChunks iirc returns a mutable ubyte[] range, not an 
immutable(ubyte)[]. The easiest way to fix this would be to 
change the foreach variable to ubyte[] and make an immutable 
duplicate of it when sending via idup.


wbuf is inferred to be an OutBuffer but then you assign an 
immutable(ubyte)[] to it in your foreach loop; a type error.

Re: Release D 2.071.0

[Márcio Martins via Digitalmars-d-announce]

On Sunday, 10 April 2016 at 20:18:28 UTC, Lewis wrote:

On Thursday, 7 April 2016 at 07:44:48 UTC, Nordlöw wrote:

On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote:

Glad to announce D 2.071.0.


I read somewhere recently about performance regressions in 
DMD. Were these related the import and module fixes? Were they 
fixed? Do they depend on any dmd switches?


Thanks anyway!


I just updated one of my projects from 2.069.0 to 2.071.0, and 
saw the build time jump from ~1.7s to ~2.5s. Take this single 
informal data point with a huge grain of salt obviously, but I 
am also curious about the details of this. DMD's speed is one 
of D's selling points to me, and I might roll back until 
performance improves if there isn't a straightforward fix.


Agreed though, otherwise a great release. Thanks for everyone's 
hard work!



Late to the party, but congratulations and great work on another 
impressive release! Thanks to everyone involved!



Just wanted to report a very large decrease in build performance.
Compare a debug build on Ubuntu 16.04 64-bit with ld.gold.

with 2.070.2:
real0m9.775s
user0m9.036s
sys 0m0.700s

with 2.071.0:
real0m45.011s
user0m41.760s
sys 0m3.144s


Since this release is not critical for us, despite including many 
great changes, we will also stick to DMD 2.070.2 and hope for a 
fix in a future release, if at all possible.

Re: Inheritance of mixin

[tsbockman via Digitalmars-d]

On Saturday, 30 April 2016 at 01:06:18 UTC, Andrew Benton wrote:
Additionally, any libraries that provide a base class with a 
mixin require inheritors to know about that mixin and provide 
it in their own code.  It certainly isn't going to happen in 
every case, but if the needed functionality is provided by 
mixins, then users of the library could have problems.


I spent a while trying to figure out how to automatically verify 
that a mixin required by a class hierarchy is included in all 
derived classes, and failed to come up with a general purpose 
solution. (I found a partial solution involving a `this T` 
templatized constructor, but it had a lot of problems.) So, I 
agree now that this is a problem worth solving.


It could be fixed by extending template mixins as you and others 
have proposed.


Another possible solution would be to fix `this T` template 
functions to be virtual, and automatically generate an override 
for each derived class. This would directly solve the most common 
use case, and also provide an (awkward) way to automatically 
verify mixin inclusion in derived classes for more complex 
scenarios.

Threads

[vino via Digitalmars-d]

Hi All,

 I am a newbie for D programming and need some help, I am trying 
to write a program using the example given in the book The "D 
Programming Language" written by "Andrei Alexandrescu" with few 
changes such as the example program read the input from stdin and 
prints the data to stdout, but my program reads the input from 
the file(readfile.txt) and writes the output to another 
file(writefile.txt), and I am getting the below errors while 
compiling


Error:

[root@localhost DProjects]# dmd readwriteb.d
readwriteb.d(7): Error: cannot implicitly convert expression 
(__aggr2859.front()) of type ubyte[] to immutable(ubyte)[]
readwriteb.d(15): Error: cannot implicitly convert expression 
(receiveOnly()) of type immutable(ubyte)[] to 
std.outbuffer.OutBuffer

[root@localhost DProjects]#

Version: DMD64 D Compiler v2.071.0

Code:

import std.algorithm, std.concurrency, std.stdio, std.outbuffer, 
std.file;


void main() {
   enum bufferSize = 1024 * 100;
   auto file = File("readfile.txt", "r");
   auto tid = spawn();
   foreach (immutable(ubyte)[] buffer; file.byChunk(bufferSize)) {
  send(tid, buffer);
   }
}

void fileWriter() {
   auto wbuf  = new OutBuffer();
   for (;;) {
  wbuf = receiveOnly!(immutable(ubyte)[])();
  write("writefile.txt", wbuf);
   }
}

From,
Vino.B

[Issue 15973] nextPow2 and truncPow2 rely on processor specific behavior

[via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/6d8f0b8285c67422f0463b30d5afc9c82c6d3dfb
Fixed Issue 15973: nextPow2 and truncPow2 rely on processor specific behavior

https://github.com/dlang/phobos/commit/aa8cf8646f1cedb058a51465da5b962f98b42cd7
Merge pull request #4268 from JackStouffer/issue15973

[Issue 15973]: nextPow2 and truncPow2 rely on processor specific …

--

Re: My favourite game: DMD guess the error reason.

[Steven Schveighoffer via Digitalmars-d]

On 5/2/16 3:13 AM, Iain Buclaw wrote:

Here's a small puzzle, in which there are both a simple and cryptic
combined. To make it easier, I've added a some multiple choice answers
at the bottom.

Winner of the simple puzzle gets a free beer from me at dconf.
Winner of the cryptic puzzle gets a free meal.


Q: What is the explanation for this error when building std.bigint?
---
$ aarch64-linux-gnu-gdc -o std/bigint.o -Wall -Werror -g -frelease -O2
-nostdinc -pipe -Wno-deprecated -c std/bigint.d

std/uni.d:2627:50: error: template std.algorithm.searching.countUntil
cannot deduce function from argument types !("a[0] >
0x80")(CodepointInterval[]), candidates are:
std/algorithm/searching.d:684:11: note:
std.algorithm.searching.countUntil(alias pred = "a == b", R, Rs...)(R
haystack, Rs needles) if (isForwardRange!R && Rs.length > 0 &&
isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) &&
is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length == 1 ||
is(typeof(countUntil!pred(haystack, needles[1..__dollar])
std/algorithm/searching.d:772:11: note:
std.algorithm.searching.countUntil(alias pred = "a == b", R, N)(R
haystack, N needle) if (isInputRange!R &&
is(typeof(binaryFun!pred(haystack.front, needle)) : bool))
std/algorithm/searching.d:841:11: note:
std.algorithm.searching.countUntil(alias pred, R)(R haystack) if
(isInputRange!R && is(typeof(unaryFun!pred(haystack.front)) : bool))
std/uni.d:1853:29: error: template instance
std.uni.InversionList!(GcPolicy) error instantiating
---

A:
---
[1]: Template deduction/matching failed to find a suitable candidate for
countUntil.


This answer is trivially true. It even says so in the error message :)

What I assume you mean is that one *should* match but there is a bug in 
the matching mechanism? I'd say no -- this would be too easy an answer



[2]: The ptrdiff_t and size_t types have a different size.


Wow, it would be a copy-paste error of some sort? An interesting 
possibility. But I'm going to say no, I don't see how this comes into 
play for the template constraints.



[3]: An untested version path had a semantic error.


This is a possibility, but not very likely (in terms of errors that are 
prone to occur).



[4]: An untested template instantiation had a missing member.


This has my vote. I've had this bite me many times...


[5]: The template function core.varargs.va_arg does not exist.


haha!


[6]: A static assert was triggered in std.math.


No, but again possible. If this is the problem, it comes down to the 
issues with is(typeof(some code)) that have been discussed lately.



[7]: The std.format module does not support 128-bit reals.


I'd say no, because I don't see how it relates to the error messages.


[8]: The compiler didn't add a predefined version for little/big endian.


ugh. How are we to guess at your environment? ;) I'd say no.


[9]: The order that modules are imported on AArch64 unearthed a bug in
the semantic pass.


Possible. Still going with 4.

-Steve

Re: Walter's Famous German Language Essentials Guide

[Jonathan M Davis via Digitalmars-d]

On Mon, 02 May 2016 13:55:35 +0100
Russel Winder via Digitalmars-d  wrote:

> On Mon, 2016-05-02 at 12:18 +, Claude via Digitalmars-d wrote:
> […]
> >
> > In french, there are 2 specials cases about gender. "orgue" 
> > (organ) and "amour" (love) are masculine on singular, and 
> > feminine on plural.
>
> Oh FFS. And they say English is a difficult language.

LOL. Well, every language has its quirks - especially with the commonly used
words (they probably get munged the most over time, because they get used
the most), but I've found that French is far more consistent than English -
especially when get a grammar book that actually explains things rather than
just telling you what to do. English suffers from having a lot of different
sources for its various words. It's consistent in a lot of ways, but it's a
huge mess in others - though I for one think that the fact that English has
no gender like languages such as French and German is a huge win.

In any case, learning any new language is hard - especially the farther it
is from your own (e.g. Asian languages are going to generally be pretty
brutal to learn for someone speaking a European languages).

- Jonathan M Davis

Re: My favourite game: DMD guess the error reason.

[Lass Safin via Digitalmars-d]

On Monday, 2 May 2016 at 07:13:17 UTC, Iain Buclaw wrote:
Here's a small puzzle, in which there are both a simple and 
cryptic combined. To make it easier, I've added a some multiple 
choice answers at the bottom.

[...]
std/uni.d:2627:50: error: template 
std.algorithm.searching.countUntil cannot deduce function from 
argument types !("a[0] > 0x80")(CodepointInterval[]), 
candidates are:

[...]
[1]: Template deduction/matching failed to find a suitable 
candidate for countUntil.

[...]


1

Re: Slides bevorehand

[Brad Anderson via Digitalmars-d]

On Monday, 2 May 2016 at 15:59:27 UTC, Benjamin Thaut wrote:

Hi,

I'm wondering if it would be a good idea to put up my slides 
before the talk. And when. On the day of the talk? Today? 
Tomorrow (Start of the Conference)?


I assume if you wanted to do this you would simply do a PR to 
the dconf.org site on GitHub?


Kind Regards
Benjamin Thaut


It could be nice to have them available in case the livestream 
doesn't show them very well (bad angle or blown out projection).

Slides bevorehand

[Benjamin Thaut via Digitalmars-d]

Hi,

I'm wondering if it would be a good idea to put up my slides 
before the talk. And when. On the day of the talk? Today? 
Tomorrow (Start of the Conference)?


I assume if you wanted to do this you would simply do a PR to the 
dconf.org site on GitHub?


Kind Regards
Benjamin Thaut

Re: My favourite game: DMD guess the error reason.

[Iain Buclaw via Digitalmars-d]

On Monday, 2 May 2016 at 13:17:13 UTC, Marco Leise wrote:
I don't have an ARMv8 or emulator to test on, so I'll take a 
wild guess. Is the answer 1,2,3,4,5,6,7,8,9 ?


You are not far off from being totally utterly wrong. :-)

Discrete semantics of lambda expressions

[Xinok via Digitalmars-d]

D has a few ways of writing lambda expressions / anonymous 
functions:


x => doSomething()
{ doSomething(); }
(){ doSomething(); }

While the flexibility is great, there's a hidden issue for those 
programmers who come from different languages and are used to 
writing:


x => { doSomething(); doSomethingElse(); }

At first glance, this may seem okay but what's actually happening 
is that this is a lambda returning a lambda. The correct way 
would be to rewrite this as one of:


x => { doSomething(); doSomethingElse(); }()
(x){ doSomething(); doSomethingElse(); }

This particular issue as popped up twice in the last couple days 
alone and presumably many more times in the past:


http://forum.dlang.org/thread/qsayoktyffczskrnm...@forum.dlang.org
http://forum.dlang.org/thread/thgyqyarccinzuqhc...@forum.dlang.org

I'm proposing that we add a warning to the compiler for this 
particular case. If the programmer intended to return a lambda, 
then rewrite the expression as one of:


x => (){ doSomething(); doSomethingElse(); }
x => ({ doSomething(); doSomethingElse(); })

vibe-s3: vibe compatible s3 client

[yawniek via Digitalmars-d-announce]

vibe compatible s3 client that supports  chunked uploads.
pretty rough around the edges, but basic things work.
supports chunked uploads and thus needs at least vibe 0.7.28.

https://github.com/tamediadigital/vibe-s3
http://code.dlang.org/packages/vibe-s3

cheers
yannick

GSoC 2016 - Precise GC

[Jeremy DeHaan via Digitalmars-d-announce]

Hi everyone!

I'm a little late to the party as far as my announcement goes, 
but I have been busy reading code and doing research for my 
project.


I was selected for this year's GSoC to implement a Precise GC, 
but I'm also planning to remove the lock on allocations as 
outlined in my proposal: 
https://drive.google.com/file/d/0B-UTFTbYro4vV0ljMUlSTEc2eEU/view?usp=sharing



My repository for the code can be found here: 
https://github.com/Jebbs/druntime



I will be posting of my progress in this thread throughout the 
course of the summer, but right now I am mainly focusing on 
familiarizing myself with all of the GC code since there is quite 
a lot of it. You will probably see me pushing some updates to 
documentation between now and when GSoC officially starts, but I 
hope to have already started making progress before then.


I'll do my best to not let you all down!

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/5c7b6eac2dc7d0ba65d81d10ff7a18fe19313718
[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates are
ignored

There can be 3 types of AST node in `importedScopes`: `Module`, `TemplateMixin`
and `Nspace`.
`MixinTemplate` can also introduce imports, so we need to look into them when
doing the second
search pass.

https://github.com/dlang/dmd/commit/1231eacba1fedc38bf617654b1ba266f95edf345
Merge pull request #5724 from mathias-lang-sociomantic/fix-15925-stable

[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates are
ignored

--

[Issue 15984] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

--- Comment #4 from Denis Shelomovskij  ---
(In reply to Stewart Gordon from comment #3)
> The posted code doesn't show the problem as I try (DMD 2.071.0 Windows).  In
> order to test it, one needs to make sure C's contract fails.  (Though this
> is down to another issue, bug 6857.)

Thanks, I still can't remember how does current implementation of D contracts
work.

> But even better would be to add debugging output to I's in contract.

Parameter contains garbage, I don't think there is any need to print it.

--

Re: relative benefit of .reserve and .length

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/29/16 6:10 AM, sigod wrote:

On Thursday, 28 April 2016 at 14:08:26 UTC, Steven Schveighoffer wrote:

On 4/28/16 8:56 AM, Jay Norwood wrote:

[...]


.reserve should make an improvement for large amount of appending,
since you pre-allocate the data.

[...]


How about `assumeSafeAppend`? Does it have any positive impact on
performance?


I don't know why you would call it. assumeSafeAppend is an expensive 
no-op if you have appendable array.


-Steve

Re: GSoC 2016 - std.experimental.xml progress

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/2/16 8:25 AM, 9il wrote:

On Monday, 2 May 2016 at 08:45:59 UTC, Lodovico Giaretta wrote:

Hi,

Just a little update about my project...
After days of bugfixes, the first almost-high-level API (XMLCursor) is
now quite usable.
Now I can start working on other APIs (e.g. DOM) based on it.

If you're interested you can find some usage examples in files
benchmark.d and test.d .
Any comment is highly appreciated.

(If you missed it, the repo is
https://github.com/lodo1995/experimental.xml ).

Thank you in advance.

Lodovico Giaretta


Hello Lodovico,

Thank you for working on new xml. Please use size_t and sizediff_t
instead of uint and int in your loops:

for (auto i = 0; i < t.length; i++)

should be replaced with

foreach (size_t i; 0 .. t.length)


It's not obvious, but you identified 2 different things here.

auto i = 0 -> typeof(i) == int

size_t i = 0 -> typeof(i) == size_t

AND

use foreach instead of for loops for simple index traversal.

Note: foreach(i; 0 .. t.length) should correctly type i as size_t, there 
is no need to force it.


-Steve

Re: [OT] Swift removing minor features to piss me off

[Steven Schveighoffer via Digitalmars-d]

On 5/2/16 6:55 AM, ag0aep6g wrote:

On 02.05.2016 09:45, Jacob Carlborg wrote:

Does it matter? I thought the idea was to get the same behavior not
explicitly a range.


default0 said that D's ranges would be more awkward than a for loop. I
think D's iota is fine.

D's special syntax is even nicer, but it's a language thing. And
apparently Swift is cutting down on syntax, not adding. Something like
iota is probably doable in a library. I don't know Swift, though.


Swift has both builtin syntax and library mechanism similar to iota:

for i in 0..<5 // [0 to 5)
for i in 0...5 // [0 to 5]
for i in 0.stride(to: 5, by: 1) // [0 to 5)
for i in 0.stride(through: 5, by: 1) // [0 to 5]

You can also hack with where expressions the builtin range syntax to 
skip values like iota, but I'm almost positive this doesn't perform 
well, or at least won't in complex situations:


for i in 0..<10 where i % 2 == 0 // even numbers less than 10

I think for-in (swift) and foreach (D) are both fantastic for iterating 
a straight range or pre-determined sequence. I would never use for loops 
for a straightforward index progression (and ideally, I would ignore the 
index if at all possible).


However, there are cases where I pull out the for loop because the 
ending condition is complex, or strangely related to the index variable, 
or the increments aren't regular. For loops have so much power in such a 
succinct syntax, I can't understand why anyone would shun them as taboo 
or error prone. Seems like it's more a philosophical decision than 
practical or helpful.


And anyone who says "bleh, you can just use a while loop if you need 
that" I want to beat with a semi-colon over the head.


-Steve

Re: GSoC 2016 - std.experimental.xml progress

[Lodovico Giaretta via Digitalmars-d-announce]

On Monday, 2 May 2016 at 12:25:03 UTC, 9il wrote:

Hello Lodovico,

Thank you for working on new xml. Please use size_t and 
sizediff_t instead of uint and int in your loops:


for (auto i = 0; i < t.length; i++)

should be replaced with

foreach (size_t i; 0 .. t.length)

Best regards,
Ilya


I'll fix this. Thank you very much.

[Issue 15984] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

Stewart Gordon  changed:

   What|Removed |Added

 CC||s...@iname.com

--- Comment #3 from Stewart Gordon  ---
The posted code doesn't show the problem as I try (DMD 2.071.0 Windows).  In
order to test it, one needs to make sure C's contract fails.  (Though this is
down to another issue, bug 6857.)

But even better would be to add debugging output to I's in contract.

--
import std.stdio;

interface I
{
void f(int i)
in {
writeln(i);
assert(i == 5);
}
}

class C : I
{
void f(int i)
in { assert (false); }
body { }
}

void main()
{
I i = new C;
i.f(5);
}
--
4202755

core.exception.AssertError@bz15984.d(14): Assertion failure

0x00402D3B
0x00402103
0x00403EA7
0x00403DA8
0x0040270F
0x769DD4D1 in BaseThreadInitThunk
0x77201593 in RtlInitializeExceptionChain
0x77201566 in RtlInitializeExceptionChain
--

--

Re: So what does (inout int = 0) do?

[Steven Schveighoffer via Digitalmars-d]

On 5/1/16 7:58 PM, Seb wrote:

On Friday, 15 April 2016 at 23:05:14 UTC, Steven Schveighoffer wrote:

On 4/15/16 6:31 PM, Timon Gehr wrote:

[...]


I'm sorry, should have put on my standard disclaimer that I am not a
compiler writer :) I actually have no idea how this is done in the
compiler, just how a compiler should behave as I understand it in my
head.

[...]


inout(bool) newsgroup.revive_discussion();

can we make the compiler smart enough to solve the use-cases of inout
(=auto const/immutable deducation)?


If we can find a way to replace inout with something that does 
effectively everything inout does, then I'm all for it.


-Steve

[Issue 15984] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

--- Comment #2 from Denis Shelomovskij  ---
(In reply to Denis Shelomovskij from comment #1)
> Probably these
> contracts wasn't called before and current issue isn't really a REGRESSION
> but I will still temporary change this issue importance until correct
> REGRESSION behavior case issue is filed.

This issue is a REGRESSION, dmd 2.070 correctly passes parameters to interface
contracts.

--

Re: Command line parsing

[Wyatt via Digitalmars-d]

On Monday, 2 May 2016 at 12:52:42 UTC, Andrei Alexandrescu wrote:


This is interesting because it's what std.getopt does but the 
opposite of what GFLAGS (http://gflags.github.io/gflags/) does. 
GFLAGS allows any module in a project to define flags. I was 
thinking of adding GFLAGS-like capabilities to std.getopt but 
looks like there's no need to... thoughts?


"Gflags, the commandline flags library used within Google..."

My perspective is those last three words are pretty important.  
It's a clever idea that's great when you have a whole mountain of 
things that live and work together that were _designed_ to do so, 
but I don't think it's going to generalise well.  It's sort of 
like Bazel, which works in Google's colossal pillar of code, but 
doesn't tend to make a lot of sense for most other projects.


I could be wrong, though.  I've been using JCommander 
(http://jcommander.org/#Overview) at work this last week, and it 
hasn't been too bad.  It's a bit different though, because Java 
and the actual control over what classes you scan for options is 
still in your hands. (If I'm reading this right, Gflags isn't 
something you easily have fine control over-- you use it or you 
don't.)


-Wyatt

Re: inferred size for static array initialization

[Marco Leise via Digitalmars-d-learn]

Am Mon, 02 May 2016 13:00:27 +
schrieb Erik Smith :

> Is there a way to initialize a static array and have it's size 
> inferred (and that works for arrays of structs using braced 
> literals)?  This would make it easier to maintain longer static 
> array definitions.  The code below doesn't work when removing the 
> array size even though the array is declared as static immutable.
> 
>  import std.traits;
>  static immutable int[] a  = [1,2,3];
>  static assert(isStaticArray!(typeof(a)));  // fails
> 

Sure,

  struct S { int a, b; }

  immutable tab = { static enum S[] s = [
  {1,2},
  {3,4},
  ]; return cast(typeof(s[0])[s.length])s; }();

  static assert(isStaticArray!(typeof(tab)));  // succeeds

-- 
Marco

Re: inferred size for static array initialization

[Basile B via Digitalmars-d-learn]

On Monday, 2 May 2016 at 13:22:01 UTC, Basile B wrote:

On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size 
inferred (and that works for arrays of structs using braced 
literals)?  This would make it easier to maintain longer 
static array definitions.  The code below doesn't work when 
removing the array size even though the array is declared as 
static immutable.


import std.traits;
static immutable int[] a  = [1,2,3];
static assert(isStaticArray!(typeof(a)));  // fails


Help yourself with a template:


import std.traits;

auto toStaticArray(alias array)()
if (isArray!(typeof(array)))
{
enum size = array.length;
alias T = typeof(array.init[0])[size];
T result = array[0..size];
return result;
}

enum a = toStaticArray!([1,2,3]);
static assert(isStaticArray!(typeof(a)));  // success


Does it fit ?


Using an enum is probably a bit better


auto toStaticArray(alias array)()
if (isDynamicArray!(typeof(array)) && array.length)
{
alias T = typeof(array[0])[array.length];
enum T result = array[0..array.length];
return result;
}

[Issue 15984] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

Denis Shelomovskij  changed:

   What|Removed |Added

   Severity|major   |regression

--- Comment #1 from Denis Shelomovskij  ---
vibe.d 0.7.28+ now fails in non-release builds because of this issue. It didn't
fail before, so there is a REGRESSION is dmd 2.071. Probably these contracts
wasn't called before and current issue isn't really a REGRESSION but I will
still temporary change this issue importance until correct REGRESSION behavior
case issue is filed.

--

[Issue 7517] Interface contracts broken

[via Digitalmars-d-bugs]

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

Denis Shelomovskij  changed:

   What|Removed |Added

 CC||verylonglogin@gmail.com

--- Comment #6 from Denis Shelomovskij  ---
Please reopen if this is a cumulative issue as interface contracts are still
broken, they can't access parameters (see Issue 15984).

--

[Issue 7517] Interface contracts broken

[via Digitalmars-d-bugs]

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

Denis Shelomovskij  changed:

   What|Removed |Added

 Depends on||15984

--

[Issue 15984] New: Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

  Issue ID: 15984
   Summary: Interface contracts retrieve garbage instead of
parameters
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: contracts, wrong-code
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: verylonglogin@gmail.com
Blocks: 7517

This code should run fine:
---
interface I
{
void f(int i)
in { assert(i == 5); } // Fails
}

class C : I
{
void f(int i)
in { } // To call contract
body { }
}

void main()
{
I i = new C;
i.f(5);
}
---

Note: `(new C).f(5)` fails too but let's support correct contract
implementation (i.e. contract is called based on static type) in testcase.

--