LLVM IR influence on compiler debugging
This is a very easy to read article about the design of LLVM: http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 It explains what the IR is: The most important aspect of its design is the LLVM Intermediate Representation (IR), which is the form it uses to represent code in the compiler. LLVM IR [...] is itself defined as a first class language with well-defined semantics. In particular, LLVM IR is both well specified and the only interface to the optimizer. This property means that all you need to know to write a front end for LLVM is what LLVM IR is, how it works, and the invariants it expects. Since LLVM IR has a first-class textual form, it is both possible and reasonable to build a front end that outputs LLVM IR as text, then uses UNIX pipes to send it through the optimizer sequence and code generator of your choice. It might be surprising, but this is actually a pretty novel property to LLVM and one of the major reasons for its success in a broad range of different applications. Even the widely successful and relatively well-architected GCC compiler does not have this property: its GIMPLE mid-level representation is not a self-contained representation. That IR has a great effect on making it simpler to debug the compiler, I think this is important (and I think it partially explains why Clang was created so quickly): Compilers are very complicated, and quality is important, therefore testing is critical. For example, after fixing a bug that caused a crash in an optimizer, a regression test should be added to make sure it doesn't happen again. The traditional approach to testing this is to write a .c file (for example) that is run through the compiler, and to have a test harness that verifies that the compiler doesn't crash. This is the approach used by the GCC test suite, for example. The problem with this approach is that the compiler consists of many different subsystems and even many different passes in the optimizer, all of which have the opportunity to change what the input code looks like by the time it gets to the previously buggy code in question. If something changes in the front end or an earlier optimizer, a test case can easily fail to test what it is supposed to be testing. By using the textual form of LLVM IR with the modular optimizer, the LLVM test suite has highly focused regression tests that can load LLVM IR from disk, run it through exactly one optimization pass, and verify the expected behavior. Beyond crashing, a more complicated behavioral test wants to verify that an optimization is actually performed. [...] While this might seem like a really trivial example, this is very difficult to test by writing .c files: front ends often do constant folding as they parse, so it is very difficult and fragile to write code that makes its way downstream to a constant folding optimization pass. Because we can load LLVM IR as text and send it through the specific optimization pass we're interested in, then dump out the result as another text file, it is really straightforward to test exactly what we want, both for regression and feature tests. Bye, bearophile
Re: LLVM IR influence on compiler debugging
I implemented a compiler back end with LLVM some time ago. The IM helped a lot in both, spotting errors in IM codegen and issues with target codegen (e.g. because of some misconfiguration). You always have the high level IM available as text and the unoptimized target assembler usually is pretty similar to the IM code and thus provides a great guide deciphering the assembler. Also the fact that you can output and modify a module as IM code to try certain things is really useful sometimes.
Re: D in the cloud with cassandra ?
On Thursday, 28 June 2012 at 00:33:28 UTC, Knud Soerensen wrote: Hi. I looking into making a website for the cloud and I was wondering if anyone have tried D in connection with amazon EC2, Google app engine or similar cloud service ? You can take a look on Azure VM (linux or windows). I am also planing to use a column store as Apache's Cassandra have anyone tried it with D ? Most of blob storages provides a rest api than can be easily implemented. Knud PS.) I have been away from the D list for 4 years so this might be a stupid question, but skimming trough the change log for dmd noticed references to ICE. What does ICE stand for ?? ICE - internal compiler error.
Re: New hash API: namespace
On 25/06/12 20:04, Jesse Phillips wrote: On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote: +1 for hashes into std.hash and cryptographic primitives into std.crypto and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...), std.io. for (Outbuffer, file, ) and probably std.database or something like that for (csv, json, xml, ...) I'd be for not being so flat. I reckon, follow biology. There's kingdom.phyllus.class.order.family.genus.species But in practice, that's far too clumsy. Instead, everyone just uses genus.species. And this works even though there are more than a million species. So I reckon two levels of modules is enough. More than that is clumsy. And, if you're not sure where something should be, because there are two or more equally valid alternatives, it should probably be a level closer to the root of the tree.
Re: LLVM IR influence on compiler debugging
On 29/06/12 08:04, bearophile wrote: This is a very easy to read article about the design of LLVM: http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 That IR has a great effect on making it simpler to debug the compiler, I think this is important (and I think it partially explains why Clang was created so quickly): It's a good design, especially for optimisation tests. Although I can't see an immediate application of this for D. DMD's backend is nearly bug-free. (By which I mean, it has 100X fewer bugs than the front-end).
Re: New hash API: namespace
Don Clugston wrote: On 25/06/12 20:04, Jesse Phillips wrote: On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote: +1 for hashes into std.hash and cryptographic primitives into std.crypto and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...), std.io. for (Outbuffer, file, ) and probably std.database or something like that for (csv, json, xml, ...) I'd be for not being so flat. I reckon, follow biology. There's kingdom.phyllus.class.order.family.genus.species But in practice, that's far too clumsy. Instead, everyone just uses genus.species. And this works even though there are more than a million species. So I reckon two levels of modules is enough. More than that is clumsy. And, if you're not sure where something should be, because there are two or more equally valid alternatives, it should probably be a level closer to the root of the tree. I'd not generalize that much. Sometimes two levels are enough, sometimes there are three or more. I'd say It depends :) And yes, I think we should have std.net package. Hey, packages were created for that!
Re: Raw binary(to work without OS) in D
On 28 June 2012 18:02, Sean Kelly s...@invisibleduck.org wrote: On Jun 28, 2012, at 9:45 AM, Iain Buclaw wrote: Wouldn't it be useful if the compiler had diagnostics for all implicit allocations it makes (ie: closures, array literals)? Similar to that of the -vtls switch. These such things you may want to avoid in a freestanding environment (no link to C runtime). Yes it would. I guess the question is how to expose this. Generally speaking though, array append type operations allocate, AA insertions allocate, and non-scope delegate use allocates. I think that's it. From a user perspective? A switch that has a less ugly than -vimplicit_library_calls. Which spurts out messages like: Function %s builds a closure, func or Expression %s makes implicit allocation call to %s, expr, func -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Raw binary(to work without OS) in D
Iain Buclaw: From a user perspective? A switch that has a less ugly than -vimplicit_library_calls. Which spurts out messages like: Function %s builds a closure, func http://d.puremagic.com/issues/show_bug.cgi?id=5070 Bye, bearophile
Re: Douglas Crockford on JavaScript and bad styles
On 06/29/2012 09:13 AM, Manipulator wrote: http://www.youtube.com/channel/UCF0LH5GvQI3u9c36oAAzWXQ/videos Just watched these videos with Douglas Crockford and thought that he made some very good points. Why we still design languages that invite bad styles? That is quite obvious from Crockford's talk alone: Because that kind of language is popular. I feel that many people in the D community is the exhibitionist type of person. Let's stop! I'd have to disagree with this statement, because of the following facts: 1. There is no formal language specification. 2. There are fewer unexpected edge cases, because the language is better designed than JS. 3. The compiler does not implement them correctly, and abusing bugs is likely to result in code that changes its behaviour or becomes illegal. Because of 1, nobody can study the language specification, because of 2 and 3, finding unexpected edge cases is unproductive (you are more likely to segfault the compiler than to find exploitable behaviour), and because of 1 and 3, found edge cases are hard to successfully leverage into bad style D code. D/DMD in its current state does not support exhibitionism!
Re: Raw binary(to work without OS) in D
On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote: On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote: On 6/28/12 10:07 AM, Roman D. Boiko wrote: On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: I think just exposing them via .sig and .exp might be the way to go? sig is easy to confuse with sign .mantissa and .exp .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem. David In my BigDecimal/BigFloat modules I use .coefficient and .exponent externally but .mant and .expo internally. It would be nice to be consistent -- I can adapt to whatever is best. Paul
Inferred return types
I just noticed that the return type of a function can be inferred
without using a storage class:
@property foo ()
{
return foo;
}
void main ()
{
string str = foo;
}
Is that supposed to work? The specification says:
If it does not already have a storage class, use the auto storage class.
But @property is not a storage class. It seems I can put most of the
attributes there instead of @property, both those with and without a @.
Second, it seems it's not possible to override a method with an inferred
return type, as the example below shows:
class Foo
{
auto foo ()
{
return Foo;
}
}
class Bar : Foo
{
auto foo ()
{
return Bar;
}
}
void main ()
{
Foo f = new Bar;
writeln(f.foo());
}
Results in:
Error: function main.Bar.foo of type () overrides but is not covariant
with main.Foo.foo of type ()
--
/Jacob Carlborg
Re: Inferred return types
On 06/29/2012 09:17 PM, Jacob Carlborg wrote:
I just noticed that the return type of a function can be inferred
without using a storage class:
@property foo ()
{
return foo;
}
void main ()
{
string str = foo;
}
Is that supposed to work?
Yes.
The specification says:
If it does not already have a storage class, use the auto storage class.
But @property is not a storage class. It seems I can put most of the
attributes there instead of @property, both those with and without a @.
The spec (and the implementation as well) considers them to be storage
classes. I think the term 'storage class' should be retired.
Second, it seems it's not possible to override a method with an inferred
return type, as the example below shows:
class Foo
{
auto foo ()
{
return Foo;
}
}
class Bar : Foo
{
auto foo ()
{
return Bar;
}
}
void main ()
{
Foo f = new Bar;
writeln(f.foo());
}
Results in:
Error: function main.Bar.foo of type () overrides but is not covariant
with main.Foo.foo of type ()
--
/Jacob Carlborg
This is a bug I have run into as well, but I have missed to report it.
Re: Inferred return types
Jacob Carlborg:
Is that supposed to work?
If the D specs don't agree, then in this case I think the D specs
need to be modified.
Second, it seems it's not possible to override a method with an
inferred return type,
This seems a bug report fit for Bugzilla:
class Foo {
string foo() {
return Foo.foo;
}
}
class Bar : Foo {
override /*string*/ foo() { // compiles un-commenting string
return Bar.foo;
}
}
void main() {}
Bye,
bearophile
Re: Inferred return types
On 2012-06-29 21:25, Timon Gehr wrote: This is a bug I have run into as well, but I have missed to report it. Reported: http://d.puremagic.com/issues/show_bug.cgi?id=8318 -- /Jacob Carlborg
Re: Inferred return types
class Foo
{
auto foo ()
{
return Foo;
}
}
class Bar : Foo
{
auto foo ()
{
return Bar;
}
}
Ouch, what a terrible idea to base a class hierachy on inference.
But nonetheless covariance checking should be performed after inference.
Re: Raw binary(to work without OS) in D
On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote: On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote: On 6/28/12 10:07 AM, Roman D. Boiko wrote: On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: I think just exposing them via .sig and .exp might be the way to go? sig is easy to confuse with sign .mantissa and .exp .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem. David How about .mant and .expo? That's what I'm using in the BigDecimal/BigFloat modules as private names. The property names are .coefficient and .exponent.
Re: D in the cloud with cassandra ?
It's pretty new and has not yet started commercially but should so in the coming months. Red Hat's OpenShift Platform might catch your needs. I am not fully sure if it is capable of doing all you want, especially the Cassandra thing but a search for 'openshift diy cartridge' should bring you further. OpenShift is no IaaS but a PaaS but gives you choice on what you want to run as your cartridge as long as the binary runs on a x64 Red Hat Enterprise Linux and speaks http. On Thursday, 28 June 2012 at 00:33:28 UTC, Knud Soerensen wrote: Hi. I looking into making a website for the cloud and I was wondering if anyone have tried D in connection with amazon EC2, Google app engine or similar cloud service ? I am also planing to use a column store as Apache's Cassandra have anyone tried it with D ? Knud PS.) I have been away from the D list for 4 years so this might be a stupid question, but skimming trough the change log for dmd noticed references to ICE. What does ICE stand for ??
'' and '' are matching delimiters?
They are, according to the Nesting Delimiters table in: http://dlang.org/lex.html When exactly are they seen as nesting delimiters?
Re: '' and '' are matching delimiters?
On Saturday, June 30, 2012 07:05:04 Mehrdad wrote:
They are, according to the Nesting Delimiters table in:
http://dlang.org/lex.html
When exactly are they seen as nesting delimiters?
When they're used in delimited strings. That's the whole point of that
section. The examples are
q(foo(xxx)) // foo(xxx)
q[foo{] // foo{
but they could have included something like
qfoo{ // foo{
- Jonathan M Davis
Re: '' and '' are matching delimiters?
On Saturday, 30 June 2012 at 05:32:31 UTC, Jonathan M Davis wrote:
On Saturday, June 30, 2012 07:05:04 Mehrdad wrote:
They are, according to the Nesting Delimiters table in:
http://dlang.org/lex.html
When exactly are they seen as nesting delimiters?
When they're used in delimited strings. That's the whole point
of that
section. The examples are
q(foo(xxx)) // foo(xxx)
q[foo{] // foo{
but they could have included something like
qfoo{ // foo{
- Jonathan M Davis
Ooh I didn't understand that. lol it seems so obvious
now. _
Thanks!
foreach syntax
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
I could give him no clever answer to, so maybe someone here knows
the reasons.
Re: foreach syntax
On 06/29/2012 12:47 PM, Namespace wrote:
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
I could give him no clever answer to, so maybe someone here knows the
reasons.
I suppose it is because the usual 'for' loop is a relative of 'foreach'.
And there we (and the C world) uses ';'.
Re: foreach syntax
Namespace:
A friend of mine ask me why D's foreach isn't like C#
In D you often omit the type:
foreach (val; arr) {
Using in is better for the human programmers. But D is largely
designed to make D compilers too happy. I think Walter said that
the semicolon was preferred because it simplifies the
compiler/compilation a little.
Bye,
bearophile
Re: Concurrency in D
On Thu, 28 Jun 2012 00:34:50 +0200, Minas Mina wrote: I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). For all those appoaches, which is the preffered? For all those appoaches, which is the preffered for game programming? Thank you. Both std.concurrency and std.parallelism need core.thread in order to do what they do... -- Dejan Lekic mailto:dejan.lekic(a)gmail.com http://dejan.lekic.org
Re: foreach syntax
On Fri, 29 Jun 2012 12:47:28 +0200, Namespace wrote:
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like int[] arr = [1, 2, 3];
foreach (int val; arr) {
and not foreach (int val in arr) {
which it is more intuitive.
I could give him no clever answer to, so maybe someone here knows the
reasons.
Because
1) in is a D keyword
2) D has even shorter syntax: foreach(val; arr) {}
--
Dejan Lekic
mailto:dejan.lekic(a)gmail.com
http://dejan.lekic.org
Re: foreach syntax
On 06/29/2012 12:47 PM, Namespace wrote:
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
foreach(val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
To someone coming from C#, yes.
I could give him no clever answer to, so maybe someone here knows the
reasons.
Just because. This does not matter.
Re: foreach syntax
Timon Gehr: Just because. This does not matter. Now and then I write foreach(x;y;data) or foreach(x,y,data) or foreach(x;y,data). in avoids some of those little mistakes. Bye, bearophile
Re: foreach syntax
On 06/29/2012 01:01 PM, bearophile wrote:
Namespace:
A friend of mine ask me why D's foreach isn't like C#
In D you often omit the type:
foreach (val; arr) {
Using in is better for the human programmers.
Certainly not. (except if 'human' means 'python' or 'C#'.)
It is just as good as ';'.
But D is largely
designed to make D compilers too happy. I think Walter said that the
semicolon was preferred because it simplifies the compiler/compilation a
little.
It does not. Parsing the statements just about the same. In fact, only
2 lines in the DMD parser implementation need to be changed (slightly!)
to implement the 'in' syntax instead.
Re: foreach syntax
On 06/29/2012 04:16 PM, bearophile wrote: Timon Gehr: Just because. This does not matter. Now and then I write foreach(x;y;data) error: found ';' when expecting ')' or foreach(x,y,data) or error: found ')' when expecting ';' foreach(x;y,data). error: undefined identifier y in avoids some of those little mistakes. foreach(x in y,data)
Re: foreach syntax
On 06/29/2012 04:23 PM, Timon Gehr wrote: ... foreach(x;y,data). error: undefined identifier y BTW, it would certainly be better if this didn't actually pass the parser.
Re: foreach syntax
Timon Gehr: foreach(x in y,data) There is no way to avoid all possible mistakes, but it's easier to mistake a ; for a ,, than mistake a in for a ,. in is used for this purpose in Python, C#, and probably other languages because it's more readable than an arbitrary symbol like ;. Bye, bearophile
Re: foreach syntax
On 06/29/2012 04:34 PM, bearophile wrote: Timon Gehr: foreach(x in y,data) There is no way to avoid all possible mistakes, but it's easier to mistake a ; for a ,, than mistake a in for a ,. I don't think optimizing the grammar for error cases that are not even compilable code is worthwhile at all. in is used for this purpose in Python, C#, and probably other languages because it's more readable Probably it is used in those languages because it resembles mathematical notation, or let var in exp. I doubt there is anything deep behind it. than an arbitrary symbol like ;. Probably, but when I read code, I don't read the ';', it is just a separator and helps orientation. Making separators 'readable' is imho a non-goal. But YMMV. Patching the parser so that it accepts both forms takes 20 seconds.
Re: foreach syntax
On Friday, June 29, 2012 16:34:33 bearophile wrote: Timon Gehr: foreach(x in y,data) There is no way to avoid all possible mistakes, but it's easier to mistake a ; for a ,, than mistake a in for a ,. in is used for this purpose in Python, C#, and probably other languages because it's more readable than an arbitrary symbol like ;. And in Java, they use : rather than ; or in. This is completely subjective. I see _zero_ benefit in using in over ;. ; is nicely consistent with for, and is probably why foreach in D uses it. But regardless, it's purely a subjective choice. Walter picked what he picked. C# and python picked what they picked. Java picked what they picked. I really don't think that you can objectively argue that one is better than the other - not unless one is objectively easier to write the grammar for. Anything involving whether a person thinks in is or ; is easier to read or will cause fewer mistakes or whatnot is going to be purely subjective. - Jonathan M Davis
Re: foreach syntax
On Friday, June 29, 2012 12:47:28 Namespace wrote:
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
I could give him no clever answer to, so maybe someone here knows
the reasons.
Probably because for uses ; rather than in. But it's a purely subjective
language design decision. Walter could have used : like Java does, and it
would have worked just as well. He decided to go with ;. On the whole, we was
basing D on C++, not C#, so he didn't copy what C# was doing syntactically for
anything AFAIK. Lots of stuff like this is going to vary from language to
language, and often the decisions are arbitrary and have nothing to do with
what other languages did or are based completely on the lanugage designer's
personal preferences. If there's no technical reason for going with one over
the other (and I'm not aware of one in this case), then it's up to the
language designer to make a choice on it which is going to be completely
subjective.
- Jonathan M Davis
Re: foreach syntax
It wasn't my intention to start a syntax war. :D But i must agree, that in is a lot more readable as ;. Event : ist more readable as ;. But i just would know the real reason to this decision. Tanks to all. :) But why correct a few guys here my code? foreach (int val; is the same as foreach(val; except that i like to write which type val is. Is that against the D nature or what? P.S.: Which line must be changed to allow the in2 syntax? Just out of pure interest. Thanks.
Re: foreach syntax
On 06/29/2012 06:09 PM, Namespace wrote: It wasn't my intention to start a syntax war. :D But i must agree, that in is a lot more readable as ;. Event : ist more readable as ;. But i just would know the real reason to this decision. Tanks to all. :) But why correct a few guys here my code? It was more of a suggestion than a correction. foreach (int val; is the same as foreach(val; except that i like to write which type val is. Is that against the D nature or what? It is redundant. P.S.: Which line must be changed to allow the in2 syntax? Just out of pure interest. Thanks. Search for TOKforeach in parse.c and change the TOKsemicolon's around there to TOKin's. If you want to allow both, that should be straightforward as well.
Re: foreach syntax
It is redundant. But informative. Search for TOKforeach in parse.c and change the TOKsemicolon's around there to TOKin's. If you want to allow both, that should be straightforward as well. I will try.
Re: foreach syntax
You mean just change line 3817 to if (t-value == TOKcomma || t-value == TOKsemicolon || t-value == TOKin) ? But know i have to rebuild dmd (i use windows), and i never did this before. :/
Re: foreach syntax
You mean line 3817 change to if (t-value == TOKcomma || t-value == TOKsemicolon || t-value == TOKin) ? But i have to rebuild dmd or not? I'm a windows user and I never build dmd on my own.
Re: foreach syntax
Am 29.06.2012 18:23, schrieb Namespace: You mean line 3817 change to if (t-value == TOKcomma || t-value == TOKsemicolon || t-value == TOKin) ? But i have to rebuild dmd or not? I'm a windows user and I never build dmd on my own. Yes, you have to recompile DMD
Re: foreach syntax
On Friday, 29 June 2012 at 16:27:23 UTC, Namespace wrote: You mean just change line 3817 to if (t-value == TOKcomma || t-value == TOKsemicolon || t-value == TOKin) ? But know i have to rebuild dmd (i use windows), and i never did this before. :/ Which is easy. I write a guide as soon as time permits.
Re: foreach syntax
Which is easy. Even on Windows? :O
Re: foreach syntax
On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the
compiler still says
found 'in' when expecting ';'! if i try to write foreach (val
in vals) {.
Have i edit the wrong line in paste.c or fails my build?
Re: foreach syntax
On 06/29/2012 06:27 PM, Namespace wrote: You mean just change line 3817 to if (t-value == TOKcomma || t-value == TOKsemicolon || t-value == TOKin) ? But know i have to rebuild dmd (i use windows), and i never did this before. :/ You'll also have to change the line that says expect(TOKsemicolon);
Re: foreach syntax
On 06/29/2012 07:47 PM, Namespace wrote:
On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the compiler
still says
found 'in' when expecting ';'! if i try to write foreach (val in vals) {.
Have i edit the wrong line in paste.c or fails my build?
You have to edit both relevant lines.
Re: foreach syntax
You'll also have to change the line that says expect(TOKsemicolon); In what? comment out?
How would I sort an associative array by value?
Or more generally does D have a library function so I can sort one array based on sorting the contents of another? I don't want to just sort the values alone, the associated keys would need to move with them. I can think of ways of doing it myself, just wondering if there's an elegant way built in.
Re: foreach syntax
On 06/29/2012 07:50 PM, Namespace wrote: You'll also have to change the line that says expect(TOKsemicolon); In what? comment out? Looking at some other parts of the parse.c source reveals that if(token.value == TOKin) nextToken(); else expect(TOKsemicolon); might get you going.
Re: How would I sort an associative array by value?
On 06/29/2012 07:52 PM, ixid wrote: Or more generally does D have a library function so I can sort one array based on sorting the contents of another? sort!a[0]b[0](zip(basedOnThis, alsoSortThis)); This sorts both ranges in-place based on the contents of the first range.
Re: foreach syntax
On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote:
On 06/29/2012 07:50 PM, Namespace wrote:
You'll also have to change the line that says
expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that
if(token.value == TOKin) nextToken(); else expect(TOKsemicolon);
might get you going.
I think i'm to stupid for that, sry. I comment out check (just
for testing) but then i get much more errors if i try to compile
foreach (val in vals) {.
Re: foreach syntax
On 06/29/2012 08:04 PM, Namespace wrote: On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote: On 06/29/2012 07:50 PM, Namespace wrote: You'll also have to change the line that says expect(TOKsemicolon); In what? comment out? Looking at some other parts of the parse.c source reveals that if(token.value == TOKin) nextToken(); else expect(TOKsemicolon); might get you going. I think i'm to stupid for that, sry. My bad: Replacing the line with the following, together with the other change you made, works: if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Re: How would I sort an associative array by value?
Thank you!
Re: foreach syntax
My bad: Replacing the line with the following, together with the other change you made, works: if(token.value == TOKin) nextToken(); else check(TOKsemicolon); Impressive, thanks a lot, sometimes I'm a bit stupid. :) Last question: It works fine, but i'm getting now DMD v2.059 DEBUG if i compile. Do I need a special flag by recompiling?
Re: foreach syntax
On 06/29/2012 08:18 PM, Namespace wrote: My bad: Replacing the line with the following, together with the other change you made, works: if(token.value == TOKin) nextToken(); else check(TOKsemicolon); Impressive, thanks a lot, sometimes I'm a bit stupid. :) Last question: It works fine, but i'm getting now DMD v2.059 DEBUG if i compile. Do I need a special flag by recompiling? I don't have a windows system handy, but you could try the following: make -fwin32.mak release
Re: foreach syntax
make -fwin32.mak release That simple... :) Many thanks!
opCall() @property
struct X
{
bool _x;
A opCall(bool x) @property {_x = x;return this;}
}
void main()
{
X a;
x = false;//the same that x.opCall(false)?
}
I thought that I could replace these opAssign, but the compiler
does not agree with me.
But why?
Re: opCall() @property
This works:
import std.stdio;
struct X {
private:
bool _x;
public:
this(bool x) {
_x = x;
}
@property
bool Get() inout {
return this._x;
}
alias Get this;
typeof(this) opAssign(bool x) {
this._x = x;
return this;
}
}
void main()
{
X a = false;
writeln(a);
a = true;
writeln(a);
}
Re: foreach syntax
On Friday, June 29, 2012 18:16:23 Namespace wrote: It is redundant. But informative. It's very common in D to not put the type unless it's absolutely necessary (e.g. use auto everywhere). This can be both good and bad for code readability and maintenance, but it's particularly useful with generic code, which is generally promoted quite heavily. So, I think that you'll find that most of the people around here generally don't explicitly use the type unless they need to (though there's always someone who's an exception). - Jonathan M Davis
Re: foreach syntax
But there is no overhead or something else _if_ i put the type, or?
Re: foreach syntax
On 06/29/2012 09:51 PM, Namespace wrote: But there is no overhead or something else _if_ i put the type, or? There is a slight typing and compilation overhead. Nothing significant.
Re: opCall() @property
On Friday, 29 June 2012 at 19:37:50 UTC, Namespace wrote:
This works:
import std.stdio;
struct X {
private:
bool _x;
public:
this(bool x) {
_x = x;
}
@property
bool Get() inout {
return this._x;
}
alias Get this;
typeof(this) opAssign(bool x) {
this._x = x;
return this;
}
}
void main()
{
X a = false;
writeln(a);
a = true;
writeln(a);
}
I see, I just thought that opCall @ property equivalent opAssign
and wanted to check it out, and now I would be interested to
understand why it is not
Re: foreach syntax
On Friday, June 29, 2012 21:51:20 Namespace wrote: But there is no overhead or something else _if_ i put the type, or? No. It's like auto. The type is inferred. It's all statically typed and strongly typed. It's not like it figures out the type at runtime or anything like that. It's all done at compile time. It's just like C++11's auto. It makes refactoring code a lot easier, and it makes generic code a _lot_ easier to write. Without auto, std.algorithm would pretty much be impossible (you _could_ do it, but it would be so disgusting that no one would want to use it, because all of those compound range types get truly hideous if you actually look at the types themselves - voldemort types have reduced that problem, but they'd be impossible without auto anyway). It's up to you whether you want to put types explicitly or use let them be inferred with auto or in foreach loops, but it's more or less common practice at this point to use type inferrence very heavily and to avoid using types explicitly except when you need to. - Jonathan M Davis
Re: opCall() @property
On Friday, June 29, 2012 21:08:05 Zhenya wrote:
struct X
{
bool _x;
A opCall(bool x) @property {_x = x;return this;}
}
void main()
{
X a;
x = false;//the same that x.opCall(false)?
}
I thought that I could replace these opAssign, but the compiler
does not agree with me.
But why?
You're not actually using opCall anywhere. opCall as a property actually makes
no sense, since the _only_ way that it's triggered is with parens. When
compiling with -property, your opCall is probably uncallable except by calling
it explicitly (e.g. x.opCall = false).
You could overload opAssign to do what you're trying to do, or you could use
alias this.
struct X
{
bool _x;
X opAssign(bool value)
{
_x = value;
return this;
}
}
or
struct X
{
bool _x;
alias _x this;
}
If all you want is assignment though, then just overload opAssign, since alias
enables a number of implicit conversions.
- Jonathan M Davis
Re: foreach syntax
On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote: On 06/29/2012 09:51 PM, Namespace wrote: But there is no overhead or something else _if_ i put the type, or? There is a slight typing and compilation overhead. Nothing significant. You missed a slight reading overhead.
Re: foreach syntax
On 06/29/2012 10:02 PM, Roman D. Boiko wrote: On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote: On 06/29/2012 09:51 PM, Namespace wrote: But there is no overhead or something else _if_ i put the type, or? There is a slight typing and compilation overhead. Nothing significant. You missed a slight reading overhead. Good catch.
Re: opCall() @property
On Friday, June 29, 2012 21:54:42 Zhenya wrote:
I see, I just thought that opCall @ property equivalent opAssign
and wanted to check it out, and now I would be interested to
understand why it is not
I don't see how you could think that it _would_ be. The _only_ way that opCall
can be invoked is by using the variable as if it were a function.
struct X
{
bool _x;
A opCall(bool x) {_x = x;return this;}
}
x(false);
Without those parens, the compiler has no idea that you're trying to use
opCall. opCall is specifically for being able to call a variable as if it were
a function. By using =, you're making the compiler look for opAssign
x = false;
because that's the function for overloading =. You're only going to be able to
make a function a property when it would be used as a function if it wasn't
declared as a property, and neither opCall or opAssign is used as a function
(e.g x.opCall(), x.opAssign()). They're both overloading operators. @property
is specifically for making a function act as if it were a variable, and
overloaded operators aren't used as either functions or variables. They
overload _operators_.
Off the top of my head, the _only_ overloaded operator that I can think of
where it would make any sense to declare it @property would be opDispatch,
because it's replacing function calls, but there are problems with that,
because you can't have two opDispatches, so you can't use it for both
properties and normal functions.
- Jonathan M Davis
Re: opCall() @property
On Friday, 29 June 2012 at 20:13:58 UTC, Jonathan M Davis wrote:
On Friday, June 29, 2012 21:54:42 Zhenya wrote:
I see, I just thought that opCall @ property equivalent
opAssign
and wanted to check it out, and now I would be interested to
understand why it is not
I don't see how you could think that it _would_ be. The _only_
way that opCall
can be invoked is by using the variable as if it were a
function.
struct X
{
bool _x;
A opCall(bool x) {_x = x;return this;}
}
x(false);
Without those parens, the compiler has no idea that you're
trying to use
opCall. opCall is specifically for being able to call a
variable as if it were
a function. By using =, you're making the compiler look for
opAssign
x = false;
because that's the function for overloading =. You're only
going to be able to
make a function a property when it would be used as a function
if it wasn't
declared as a property, and neither opCall or opAssign is used
as a function
(e.g x.opCall(), x.opAssign()). They're both overloading
operators. @property
is specifically for making a function act as if it were a
variable, and
overloaded operators aren't used as either functions or
variables. They
overload _operators_.
Off the top of my head, the _only_ overloaded operator that I
can think of
where it would make any sense to declare it @property would be
opDispatch,
because it's replacing function calls, but there are problems
with that,
because you can't have two opDispatches, so you can't use it
for both
properties and normal functions.
- Jonathan M Davis
Thank you,I understood.
Range to array
It is terrible to use a function of std.range if you are not
using auto as type all the time.
Why isn't there a convert function for the original type?
I know array(Range) of std.array is what i want, but why do i
have to import two modules to use one?
Wouldn't it be better if std.range imports std.array implicit?
Otherwise (IMO) std.range needs some convert functions like
[code]
T[] Range(alias func, T)(T[] array) {
return func(array).array();
}
T[] Range(alias func, T, U)(T[] array, U a) {
return func(array, a).array();
}
T[] Range(alias func, T, U)(T a, U b) if (!isArray!(T)) {
return func(a, b).array();
}
[/code]
or, if you prefer, in compressed (but without the type safety):
[code]
auto Range(alias func, Args...)(Args args) {
return func(args).array();
}
[/code]
I think something like that is missing in std.range.
Re: Range to array
On Saturday, June 30, 2012 01:43:44 Namespace wrote: It is terrible to use a function of std.range if you are not using auto as type all the time. Why isn't there a convert function for the original type? I know array(Range) of std.array is what i want, but why do i have to import two modules to use one? Wouldn't it be better if std.range imports std.array implicit? Otherwise (IMO) std.range needs some convert functions like std.range already publicly import std.array. Not to mention, if you're using ranges heavily, it's not all that uncommon to not actually need std.array.array very often. In general, if you're constantly converting ranges to arrays, then I'd argue that you're doing something wrong. There are definitely times when you need to convert a range to an array, but in general, you can just pass the result of one range-based function to another and operate on the data just fine without needing to convert to arrays at all. Worst case, you convert once you're done with all of various operations that you need to do on the data. But if you're passing arrays around rather than ranges, unless you actually need arrays for some reason, you should really consider passing ranges around like Phobos does. You're code's not going to be terribly efficient if you're constantly converting the results of range-based functions into arrays, since that means allocating more memory for the same data every time that you do that. - Jonathan M Davis
why is string not implicit convertable to const(char*) ?
does anyone know why string not implicit convertable to const(char*) ?
---
import core.sys.posix.unistd;
void main()
{
// ok
unlink(foo.txt);
// failed
string file = bar.txt;
unlink(file);
}
test.d(10): Error: function core.sys.posix.unistd.unlink (const(char*))
is not callable using argument types (string)
test.d(10): Error: cannot implicitly convert expression (file) of type
string to const(char*)
Re: why is string not implicit convertable to const(char*) ?
On Saturday, June 30, 2012 02:12:22 mta`chrono wrote:
does anyone know why string not implicit convertable to const(char*) ?
---
import core.sys.posix.unistd;
void main()
{
// ok
unlink(foo.txt);
// failed
string file = bar.txt;
unlink(file);
}
test.d(10): Error: function core.sys.posix.unistd.unlink (const(char*))
is not callable using argument types (string)
test.d(10): Error: cannot implicitly convert expression (file) of type
string to const(char*)
Because it's _not_ const char*. It's an array. And passing a string directly
to a C function (which is almost the only reason that you'd want a string to
convert to a const char*) is generally _wrong_. Strings in D are _not_ zero-
terminated. String _literals_ are (they have a '\0' one character passed their
end), so as it just so happens, if string implicitly converted to const char*,
your code would work, but if your string had been created from anything other
than a string literal, it would _not_ be zero terminated. Even concatenating
two string literals results in a string which isn't zero-terminated. So,
implictly converting strinvg to const char* would just cause bugs (in fact, it
_used_ to work, and it was fixed so that it doesn't precisely because it's
behavior which just causes bugs).
What you need to do is use std.string.toStringz. It converts a string to a
zero-terminated string. It appends '\0' to the end of the string if it has to
(which could result in the string having to be reallocated to make room for
it), but if it can determine that it's unnecessary (which it can do at least
some of the time with string literals), it'll just return the string's ptr
property without doing any allocating. But since you _need_ that '\0', that's
the best that you can do. Simply passing the string's ptr property to a C
function would be wrong, since it's not zero-terminated.
Your function call should look like
unlink(toStringz(file));
Of course, you could just do std.file.remove(file), which ultimately does the
same thing and does so on all platforms rather than just POSIX, but that's a
separate issue from converting a string to a const char*.
- Jonathan M Davis
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #25 from Iain Buclaw ibuc...@ubuntu.com 2012-06-29 09:22:59 PDT --- Thanks, I'll be merging this in tonight. Does the frontend error if the alignment given is not a power of 2? ie: using align(3) should not ICE or compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] New: Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316
Summary: Regression with template functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: m...@paranoici.org
--- Comment #0 from meh. m...@paranoici.org 2012-06-29 09:53:16 PDT ---
The code:
---
import std.stdio;
void lol(string wat) ()
{
writeln(wat);
}
void lol(string wat) (string omg)
{
writeln(wat, , omg);
}
void main ()
{
lol!rulez;
}
---
The error:
---
lol.d(15): Error: template lol.lol matches more than one template declaration,
lol.d(3):lol(string wat) and lol.d(8):lol(string wat)
---
I'm too lazy to find the commit, I'm sure you'll know better than me.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8317] New: [ICE] (cast.c, line 1986) with array of lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=8317
Summary: [ICE] (cast.c, line 1986) with array of lambdas
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-06-29 10:01:00 PDT ---
void main() {
int function()[] foo = [() = 1, () = 'a']; // OK
int function()[] bar;
bar = [() = 1, () = 'a']; // ICE
}
DMD2.60alpha gives:
Assertion failure: 'd-purity != PUREfwdref' on line 1986 in file 'cast.c'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8317] [ICE] (cast.c, line 1986) with array of lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=8317 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from timon.g...@gmx.ch 2012-06-29 11:07:43 PDT --- Probably related to or a duplicate of issue 8309. (the assertion there fails for the same reason.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8315] Invalid nested-ref check in template constraint
http://d.puremagic.com/issues/show_bug.cgi?id=8315 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-29 11:54:02 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/cdcf6451553f49509dabe9fa363996ae4e8e1e7b fix Issue 8315 - Invalid nested-ref check in template constraint https://github.com/D-Programming-Language/dmd/commit/ec5d4da9ac7c8ed6b0ef7c75765b0624aa67a994 Merge pull request #1029 from 9rnsr/fix8315 [Regression git] Issue 8315 - Invalid nested-ref check in template constraint -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8318] New: Cannot override a method with inferred return type
http://d.puremagic.com/issues/show_bug.cgi?id=8318
Summary: Cannot override a method with inferred return type
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@me.com
--- Comment #0 from Jacob Carlborg d...@me.com 2012-06-29 12:57:04 PDT ---
The following code fails to compile:
class Foo {
auto foo() {
return Foo.foo;
}
}
class Bar : Foo {
override auto foo() {
return Bar.foo;
}
}
void main() {}
It doesn't matter if override is specified or not. The error message received
is:
Error: function main.Bar.foo of type () overrides but is not covariant with
main.Foo.foo of type ()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8315] Invalid nested-ref check in template constraint
http://d.puremagic.com/issues/show_bug.cgi?id=8315 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #26 from Walter Bright bugzi...@digitalmars.com 2012-06-29 15:18:16 PDT --- Currently, it does not. I regard that as a separate issue, however. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-06-29 15:19:52 PDT --- It does match both. Not sure what you expect it to do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8319] New: selective scoped import
http://d.puremagic.com/issues/show_bug.cgi?id=8319
Summary: selective scoped import
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-06-29
15:21:41 PDT ---
..doesn't work
for example:
auto z(T)(T x) {
import std.traits: isPointer;
static assert(isPointer!T);
return 1;
}
void main() {
z(1);
z(a.ptr);
}
gives me:
test.d(3): Error: template instance isPointer!(int) template 'isPointer' is not
defined
test.d(8): Error: template instance test.z!(int) error instantiating
test.d(3): Error: template instance isPointer!(immutable(char)*) template
'isPointer' is not defined
test.d(9): Error: template instance test.z!(immutable(char)*) error
instantiating
whereas:
auto z(T)(T x) {
import std.traits;
static assert(isPointer!T);
return 1;
}
void main() {
z(1);
z(a.ptr);
}
sees isPointer and asserts as expected.
dmd 2.059.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #2 from timon.g...@gmx.ch 2012-06-29 16:25:29 PDT --- Isn't it a function call where the parens were left out? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8319] selective scoped import
http://d.puremagic.com/issues/show_bug.cgi?id=8319 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-06-29 16:30:27 PDT --- This is a dupe, please search for it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-29 16:45:53 PDT --- Isn't it a function call where the parens were left out? It would be if the functions didn't have any parameters, but they both do, so I don't know quite what the compiler thinks that it is. Regardless, lol!rulez results in a function named lol which takes a single string argument when there's already such a function (albeit non-templated) which exists. It's clearly a conflict no matter what you're trying to do with it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316 --- Comment #4 from timon.g...@gmx.ch 2012-06-29 16:47:38 PDT --- (In reply to comment #3) Isn't it a function call where the parens were left out? It would be if the functions didn't have any parameters, but they both do, so I don't know quite what the compiler thinks that it is. Regardless, lol!rulez results in a function named lol which takes a single string argument when there's already such a function (albeit non-templated) which exists. It's clearly a conflict no matter what you're trying to do with it. I think you might have missed the second set of parentheses on the first template function declaration. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316 --- Comment #5 from meh. m...@paranoici.org 2012-06-29 16:50:31 PDT --- Both are template functions. The first is a template function without arguments, the second has one. I'm calling the first. It throws a dumb error when it's clear what I want to do. It's code that worked before. It's a regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316
--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-29 17:01:10
PDT ---
I think you might have missed the second set of parentheses on the first
template function declaration.
Ah, you're right. I did miss those, but it still shouldn't compile, because the
compiler doesn't know which template the programmer was trying to instantiate.
Did they mean the first one (which would then be callable) or the second (which
wouldn't, because it lacks the function arguments that it requires). The
template functions don't even exist to be checked for overloading rules until
they've been instantiated, so overloading rules have no effect here. Remember
that they actually translate to
template lol(string wat)
{
void lol()
{
writeln(wat);
}
}
template lol(string wat)
{
void lol(string omg)
{
writeln(wat, , omg);
}
}
So, when you say lol!rulez, which one is the compiler going to pick? It
doesn't know which you mean. The template signatures are identical and have no
template constraints to distinguish them. So, you have a conflict. If you did
template lol(string wat)
{
void lol()
{
writeln(wat);
}
void lol(string omg)
{
writeln(wat, , omg);
}
}
then it would work (assuming that you didn't compile with -property, since then
you'd have to do lol!rulez() rather than lol!rulez, since the lol function
isn't a property). But with how they're currently declared, you have a conflict
between two templates.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8319] selective scoped import
http://d.puremagic.com/issues/show_bug.cgi?id=8319 --- Comment #2 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-06-29 17:26:09 PDT --- (In reply to comment #1) This is a dupe, please search for it. before posting, I searched for scoped import and got nothing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8320] New: metastrings.Format and int array
http://d.puremagic.com/issues/show_bug.cgi?id=8320
Summary: metastrings.Format and int array
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-06-29
18:22:46 PDT ---
Format does not properly format.
code:
import std.metastrings;
void main() {
static assert(false, Format!(abc %s, [1,2,3]));
}
produces:
test.d(3): Error: static assert ['a','b','c',' ','\x01','\x02','\x03']
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8321] New: std.range.put doesnt work with RefCounted output range
http://d.puremagic.com/issues/show_bug.cgi?id=8321
Summary: std.range.put doesnt work with RefCounted output
range
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-06-29 21:44:53 PDT ---
Test case:
import std.typecons, std.range;
struct S {
void put(int[] a){}
void put(int n){}
}
void main() {
S s;
put(s, 1); // OK
put(s, [1]);// OK
auto rs = RefCounted!S();
put(rs, 1);// doesn't work
put(rs, [1]); // doesn't work
}
To fix this issue, both Phobos and dmd needs to be fixed.
- std.traits.hasMembers doesn't see the members through alias this.
- There is no way to check whether a type T has a member xxx or not, while
avoiding UFCS.
I've conceived following technique, but doesn't work with current dmd.
struct T { void put(){} }
alias T.put X; // Type.member doesn't test UFCS,
// but getting symbol of xxx would work!
struct S { T t; alias t this; }
alias S.put X; // Getting symbol through alias this doesn't work...
I think we need to fix bug 4617.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8319] selective scoped import
http://d.puremagic.com/issues/show_bug.cgi?id=8319 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-29 21:48:47 PDT --- This is a dup of issue 7494, and it's already fixed in 2.060head. *** This issue has been marked as a duplicate of issue 7494 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7494] Selective import does not work inside a function
http://d.puremagic.com/issues/show_bug.cgi?id=7494 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||ellery-newco...@utulsa.edu --- Comment #10 from Kenji Hara k.hara...@gmail.com 2012-06-29 21:48:47 PDT --- *** Issue 8319 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8316] Regression with template functions
http://d.puremagic.com/issues/show_bug.cgi?id=8316
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #7 from Kenji Hara k.hara...@gmail.com 2012-06-29 22:14:10 PDT ---
(In reply to comment #6)
I think you might have missed the second set of parentheses on the first
template function declaration.
Ah, you're right. I did miss those, but it still shouldn't compile, because
the
compiler doesn't know which template the programmer was trying to instantiate.
Did they mean the first one (which would then be callable) or the second
(which
wouldn't, because it lacks the function arguments that it requires). The
template functions don't even exist to be checked for overloading rules until
they've been instantiated, so overloading rules have no effect here. Remember
that they actually translate to
[snip]
So, when you say lol!rulez, which one is the compiler going to pick? It
doesn't know which you mean. The template signatures are identical and have no
template constraints to distinguish them. So, you have a conflict.
I think it should be compile.
In D language, template functions, that is a template contains one function
declaration, is specially treated in its call, and it is priority than normal
template lookup/instantiation rule.
In this case, compiler knows the the two lol's are template functions, so such
special rule should be applied.
In current dmd without -property switch, lol!rulez should be implicitly
converted to lol!rulez(), and matches to the first declaration of lol.
Furthermore says, even if you add @property and use -property, following code
doesn't work.
@property void lol(string wat) ()
{
writeln(wat);
}
@property void lol(string wat) (string omg)
{
writeln(wat, , omg);
}
void main()
{
lol!rulez;// should call the first
lol!rulez = xxx;// should call the second
}
test.d(13): Error: template test.lol matches more than one template
declaration, test.d(3):lol(string wat) and test.d(7):lol(string
wat)
test.d(14): Error: template test.lol matches more than one template
declaration, test.d(3):lol(string wat) and test.d(7):lol(string
wat)
It seems to me that is definitely correct code, but if we make this issue
invalid, such property overloading would also become 'invalid'. I cannot accept
it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8322] New: std.string.chomp does not handle combining characters correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8322 Summary: std.string.chomp does not handle combining characters correctly Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-29 22:47:40 PDT --- These two succeed: assert(equal(chomp(hello \u00E9, \u00E9), hello )); assert(equal(chomp(hello e\u0301, e\u0301), hello )); These two fail: assert(equal(chomp(hello \u00E9, e\u0301), hello )); assert(equal(chomp(hello e\u0301, \u00E9), hello )); It's because chomp makes the erroneous assumption that if a string ends with the delimiter, the code points match exactly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
