Re: Rebind template(bug?)

On Monday, 22 August 2016 at 19:56:08 UTC, ag0aep6g wrote: So this is just to avoid typing out `class Pug : Dog {...} class Dog : Animal {...} class Animal {...}`? This allows you to create different inheritance chains with the same components quickly and easily. I don't know any use case, but

Re: Rebind template(bug?)

On 08/22/2016 08:54 PM, Engine Machine wrote: Yeah, but a name means nothing. Change it if you want ;) Even with a better name it still requires a good amount of thinking by the reader to see what's going on. [...] What it achieves is a uniform way to create a hierarchical relationship

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 18:48:12 UTC, ag0aep6g wrote: You can take this further with template constraints. Gives it a more uniform appearance at the price of some repetition: class T() { int x; } class T(A...) : T!(A[0..$-1]) if (A.length > 0 && A[$-1] == "Animal") { int

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 18:04:43 UTC, Engine Machine wrote: How do you seriously think this is cleaner/simpler? 1. No extra encrypted things, such as InstantiateOrEmptySeq 2. Much more understandable. You have two classes. No. I have one template with two specializations. Class template

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 18:48:12 UTC, ag0aep6g wrote: On 08/22/2016 08:04 PM, Engine Machine wrote: How do you seriously think this is cleaner/simpler? You have two classes. Their is no uniformity between them. You have uniformity between all the derived classes then have a special case

Re: Rebind template(bug?)

On 08/22/2016 08:04 PM, Engine Machine wrote: How do you seriously think this is cleaner/simpler? You have two classes. Their is no uniformity between them. You have uniformity between all the derived classes then have a special case for the base class. A certain easy to follow pattern is set up

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 07:54:36 UTC, Jack Applegame wrote: On Monday, 22 August 2016 at 00:43:00 UTC, Engine Machine wrote: The following code works and does what I want! template InstantiateOrEmptySeq(alias tmpl, args...) { alias Seq(T...)=T; static if (args.length > 0)

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 00:43:00 UTC, Engine Machine wrote: The following code works and does what I want! template InstantiateOrEmptySeq(alias tmpl, args...) { alias Seq(T...)=T; static if (args.length > 0) alias InstantiateOrEmptySeq = tmpl!(args[0 .. $-1]); else

Re: Rebind template(bug?)

On Monday, 22 August 2016 at 00:22:48 UTC, ag0aep6g wrote: On 08/22/2016 12:06 AM, Engine Machine wrote: T!()'s "data" is specified in the class just like all the other derivations. I don't want to have to specify an external base class as in your InstaniateOrBase. Why? Because!!! (There

Re: Rebind template(bug?)

On 08/22/2016 12:06 AM, Engine Machine wrote: T!()'s "data" is specified in the class just like all the other derivations. I don't want to have to specify an external base class as in your InstaniateOrBase. Why? Because!!! (There should be no need to, and if one goes this route of creating

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 21:11:37 UTC, ag0aep6g wrote: On 08/21/2016 09:29 PM, Engine Machine wrote: I know you like to play the right or wrong game, but did you ever learn that a single example does not prove the truth of something? But you can show in a single example that something

Re: Rebind template(bug?)

On 08/21/2016 09:29 PM, Engine Machine wrote: I know you like to play the right or wrong game, but did you ever learn that a single example does not prove the truth of something? But you can show in a single example that something doesn't work. You tried to do that, and you did it with a

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 20:36:54 UTC, Engine Machine wrote: On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta wrote: [...] You're right. I didn't realize that variables could be shadowed in classes. Seems dangerous. D doesn't allow shadowing in a normal context and gives an

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta wrote: On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote: [...] The problem of this code has nothing to do with aliases. They work correctly. The problem is variable shadowing. In the following code, Child has two x

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote: I know you like to play the right or wrong game, but did you ever learn that a single example does not prove the truth of something? How about something more complex? Your demagogy will not help you learn the basics of the D

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta wrote: On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote: [...] The problem of this code has nothing to do with aliases. They work correctly. The problem is variable shadowing. In the following code, Child has two x

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote: [...] The problem of this code has nothing to do with aliases. They work correctly. The problem is variable shadowing. In the following code, Child has two x variables, one of which is only accessible from a Parent reference,

Re: Rebind template(bug?)

On Sunday, 21 August 2016 at 06:28:25 UTC, Jack Applegame wrote: On Sunday, 21 August 2016 at 00:06:07 UTC, Engine Machine wrote: On Saturday, 20 August 2016 at 22:21:00 UTC, ag0aep6g wrote: On 08/21/2016 12:11 AM, Engine Machine wrote: Is there a way to rebind the arguments of a template?

Re: arsd png bug

On Tuesday, 21 June 2016 at 00:31:51 UTC, Adam D. Ruppe wrote: On Monday, 20 June 2016 at 21:39:45 UTC, Joerg Joergonson wrote: adding if (i >= previousLine.length) break; prevents some crashes and seems to work. So previousLine should be either the right length or null, so I put in

Re: arsd png bug

On Monday, 20 June 2016 at 21:39:45 UTC, Joerg Joergonson wrote: adding if (i >= previousLine.length) break; prevents some crashes and seems to work. So previousLine should be either the right length or null, so I put in one test. Can you try it on your test image? BTW I do a few

Re: arsd png bug

On Monday, 20 June 2016 at 21:53:42 UTC, Alex Parrill wrote: You'd probably get better results by filing an issue with the project's bug tracker [1]. Also by including a sample image that causes the crash. It doesn't make much of a difference to me, it all just ends up in my email inbox

Re: arsd png bug

On Monday, 20 June 2016 at 21:39:45 UTC, Joerg Joergonson wrote: 1810: case 3: auto arr = data.dup; foreach(i; 0 .. arr.length) { auto prev = i < bpp ? 0 : arr[i - bpp];

Re: imports && -run [Bug?]

On Friday, 13 May 2016 at 06:33:40 UTC, Jacob Carlborg wrote: Even better is to use "rdmd" which will automatically track and compile dependencies. but i should warn about annoing bug with local import http://forum.dlang.org/post/mailman.1984.1373610213.13711.digitalmar...@puremagic.com

Re: imports && -run [Bug?]

On 2016-05-13 08:27, Andrew Edwards wrote: I fail to see why the compiler would be less capable at this task than rdmd. Since it is already build to accept multiple input files and knows more about what's going on during compilation than rdmd will ever know, in does not make sense that it

Re: imports && -run [Bug?]

On 2016-05-13 08:10, tsbockman wrote: According to the DMD compiler manual, the -run switch only accepts a single source file: -run srcfile args... After the first source file, any further arguments passed to DMD will be interpreted as arguments to be passed to the program being run. To

Re: imports && -run [Bug?]

On 5/13/16 3:10 PM, tsbockman wrote: On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote: command: dmd -run mod inc output: Undefined symbols for architecture x86_64: "_D3inc5printFZv", referenced from: __Dmain in mod.o ld: symbol(s) not found for architecture x86_64 clang:

Re: imports && -run [Bug?]

On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote: command: dmd -run mod inc output: Undefined symbols for architecture x86_64: "_D3inc5printFZv", referenced from: __Dmain in mod.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit

Re: Is it bug compiler?

On 5/12/16 9:20 AM, MGW wrote: Windows 7 32bit --- import std.stdio; import std.conv; class CFormaMain { ~this() { char[] zz = [ 'A', 'B', 'C' ]; This allocates. Allocations are not allowed in GC collection cycle. -Steve

Re: Is it bug compiler?

On Thursday, 12 May 2016 at 13:20:35 UTC, MGW wrote: Windows 7 32bit --- import std.stdio; import std.conv; class CFormaMain { ~this() { char[] zz = [ 'A', 'B', 'C' ]; writeln(to!string(zz)); } } int main(string[] args) {

Re: RefCounted / DMD bug

On Saturday, 16 April 2016 at 14:50:07 UTC, ag0aep6g wrote: On 16.04.2016 02:56, Erik Smith wrote: I'm getting a strange assertion/crash involving RefCounted and I've reduced it down to the isolated case (see below). This is with D 2.071 and requires this version to compile. Seems to work

Re: RefCounted / DMD bug

On 16.04.2016 02:56, Erik Smith wrote: I'm getting a strange assertion/crash involving RefCounted and I've reduced it down to the isolated case (see below). This is with D 2.071 and requires this version to compile. Seems to work with git master (8da509d). Digger [1] says it's been fixed in

Re: Regression vs Bug

V Thu, 14 Jan 2016 17:32:47 + NX via Digitalmars-d-learn napsáno: > Please explain. Regression: something works before does not work anymore Bug: something does not work as expected (regression is one type of bug)

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote: Why doesn't the compiler produces an error? - import std.stdio; void main() { writeln({}); } - http://ideone.com/qTZCAd Somehow reminds me of this lambda:

Re: Feature or bug: print braces

On Friday, 15 May 2015 at 08:44:41 UTC, Ivan Kazmenko wrote: Somehow reminds me of this lambda: https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L127-L128 Maybe it generally blocks for initialization of variables:

Re: Feature or bug: print braces

On 05/14/2015 03:39 PM, Dennis Ritchie wrote: On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote: On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote: On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote: You told it to output a function literal, so it did. Yes,

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote: On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote: You told it to output a function literal, so it did. Yes, but it would be logical to deduce something like: - writeln({}); // prints literal[{}] Or the compiler

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote: On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote: On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote: You told it to output a function literal, so it did. Yes, but it would be logical to deduce something

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 22:55:43 UTC, Ali Çehreli wrote: Yes, it is weird but that value happens to be the address of the function. Here is another test: import std.stdio; void foo() pure nothrow @nogc @safe {} void main() { void printInfo(T)(T t) { writefln(%s %s,

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote: Why doesn't the compiler produces an error? - import std.stdio; void main() { writeln({}); } - http://ideone.com/qTZCAd You told it to output a function literal, so it did. (That or you told it to output a

Re: Feature or bug: print braces

Turns out that I can put into the function writeln almost any design language: - import std.stdio; void main() { writeln( { int n = 5; } ); } - http://ideone.com/Rp7gZ2

Re: Feature or bug: print braces

On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote: You told it to output a function literal, so it did. Yes, but it would be logical to deduce something like: - writeln({}); // prints literal[{}] Or the compiler will not be able to distinguish the literal from the ordinary

Re: readf error bug?

On Saturday, 9 May 2015 at 08:30:31 UTC, Dave Akers wrote: The following... import std.stdio; void main() { write(How many students are there? ); int studentCount; readf(%s, studentCount); write(How many teachers are there? ); int teacherCount;

Re: readf error bug?

On Saturday, 9 May 2015 at 08:41:49 UTC, Dave Akers wrote: On Saturday, 9 May 2015 at 08:34:42 UTC, Dennis Ritchie wrote: On Saturday, 9 May 2015 at 08:30:31 UTC, Dave Akers wrote: The following... import std.stdio; void main() { write(How many students are there? ); int

Re: readf error bug?

On Sat, 09 May 2015 09:23:23 +, John Colvin wrote: On Saturday, 9 May 2015 at 08:41:49 UTC, Dave Akers wrote: On Saturday, 9 May 2015 at 08:34:42 UTC, Dennis Ritchie wrote: On Saturday, 9 May 2015 at 08:30:31 UTC, Dave Akers wrote: The following... import std.stdio; void main() {

Re: readf error bug?

On Saturday, 9 May 2015 at 08:34:42 UTC, Dennis Ritchie wrote: On Saturday, 9 May 2015 at 08:30:31 UTC, Dave Akers wrote: The following... import std.stdio; void main() { write(How many students are there? ); int studentCount; readf(%s, studentCount); write(How

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 15:17:32 UTC, Steven Schveighoffer wrote: On 4/15/15 10:44 AM, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() { Foo foo;

Re: Detect the bug in the following code

On Thursday, 16 April 2015 at 13:52:32 UTC, ixid wrote: writeln = Now this is abused of the syntax. The important question is, can you assign a tuple and get the auto unpacking to kick in ?

Re: Detect the bug in the following code

On Thursday, 16 April 2015 at 22:48:53 UTC, Idan Arye wrote: %s %s.writefln = (foo.tuple = bar).expand; Please make a pull request: https://github.com/Hackerpilot/Idiotmatic-D

Re: Detect the bug in the following code

On Thursday, 16 April 2015 at 21:37:39 UTC, deadalnix wrote: On Thursday, 16 April 2015 at 13:52:32 UTC, ixid wrote: writeln = Now this is abused of the syntax. The important question is, can you assign a tuple and get the auto unpacking to kick in ? %s %s.writefln = (foo.tuple =

Re: Detect the bug in the following code

On 4/15/15 10:44 AM, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() { Foo foo; foo.register(10); } Easy, the bug is in DMD improperly

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: register = true; Easy, you assigned to the wrong variable, that'd quickly be obvious at runtime too with a stack overflow. I think it sucks that true and false will implicitly convert to int though, that bites people

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 14:46:56 UTC, Adam D. Ruppe wrote: On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: register = true; Easy, you assigned to the wrong variable, that'd quickly be obvious at runtime too with a stack overflow. I think it sucks that true and

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() { Foo foo; foo.register(10); } register = true

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() { Foo foo; foo.register(10); } Property assignment

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 17:28:01 UTC, John Colvin wrote: On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() {

Re: Detect the bug in the following code

On 4/15/15 1:44 PM, Caspar wrote: On Wednesday, 15 April 2015 at 17:28:01 UTC, John Colvin wrote: On Wednesday, 15 April 2015 at 14:44:48 UTC, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x);

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 15:17:32 UTC, Steven Schveighoffer wrote: Easy, the bug is in DMD improperly accepting property assignment without @property annotation :P We've found the winner!

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 15:17:32 UTC, Steven Schveighoffer wrote: On 4/15/15 10:44 AM, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x); register = true; } } void main() { Foo foo;

Re: Detect the bug in the following code

On Wednesday, 15 April 2015 at 18:25:33 UTC, w0rp wrote: On Wednesday, 15 April 2015 at 15:17:32 UTC, Steven Schveighoffer wrote: On 4/15/15 10:44 AM, Idan Arye wrote: import std.stdio; struct Foo { bool registered = false; void register(int x) { writeln(Registering , x);

Re: is it bug?

On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote: On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote: On 30.01.2015 16:31, BBaz wrote: On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: static init() { auto instance = new typeof(this)(); instance._cont = new

Re: is it bug?

On Friday, 30 January 2015 at 13:56:17 UTC, anonymous wrote: On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote: On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote: On 30.01.2015 16:31, BBaz wrote: On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: static init() { auto

Re: is it bug?

On 30.01.2015 16:56, anonymous wrote: Besides, it's a bad idea to call a member init, because it steals the name of the default initializer. It doesn't override the default initializer, it just takes its name. The compiler should not accept it, in my opinion. Good remark! I'll rename it.

Re: is it bug?

On 30.01.2015 17:04, BBaz wrote: Yes, that was the point: bad idea to call a member init. But I've missed something with inference of return type... let's call this the BMS : big-mouth-syndrom... I didn't know it could be ommitted...I thought it could be if the function has

Re: is it bug?

On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == a b) auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1]; assert(equal(r, vals)); (Tab + Enter strikes again.) That test looks wrong. So,

Re: is it bug?

The real problem is if I comment my unittest out then it compiles. Why my unittest causes this behaviour?

Re: is it bug?

On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: ``` import std.container: RedBlackTree; class Manager(TT, alias Cmp = ab) { alias Container = RedBlackTree!(TT, Cmp); Container _cont; static init() { auto instance = new typeof(this)(); instance._cont =

Re: is it bug?

On 30.01.2015 16:31, BBaz wrote: On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: static init() { auto instance = new typeof(this)(); instance._cont = new Container(); return instance; } have you tried --- static typeof(this) init() {

Re: is it bug?

On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: static init() { auto instance = new typeof(this)(); instance._cont = new Container(); return instance; } have you tried --- static typeof(this) init() { auto instance = new

Re: is it bug?

On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote: On 30.01.2015 16:31, BBaz wrote: On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: static init() { auto instance = new typeof(this)(); instance._cont = new Container(); return instance; } have you

Re: is it bug?

On 30.01.2015 16:14, anonymous wrote: On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == a b) auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1]; assert(equal(r, vals)); (Tab + Enter

Re: is it bug?

On 30.01.2015 16:35, drug wrote: On 30.01.2015 16:14, anonymous wrote: On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == a b) auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1];

Re: Another init() bug, can we deprecate yet?

On Wednesday, 7 January 2015 at 23:31:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via Digitalmars-d wrote: https://issues.dlang.org/show_bug.cgi?id=13806 For the lazy: BitArray has an init() method, which hides the property

Re: Another init() bug, can we deprecate yet?

On Thu, Jan 08, 2015 at 09:46:16AM +, Peter Alexander via Digitalmars-d wrote: On Wednesday, 7 January 2015 at 23:31:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via Digitalmars-d wrote:

Re: Another init() bug, can we deprecate yet?

On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via Digitalmars-d wrote: https://issues.dlang.org/show_bug.cgi?id=13806 For the lazy: BitArray has an init() method, which hides the property BitArray.init This, or something similar, appears every few months. Walter has said in

Re: Another init() bug, can we deprecate yet?

On Wednesday, 7 January 2015 at 22:03:01 UTC, Peter Alexander wrote: Can we just deprecate it? At the very least deprecate functions named init(). There's a check for that: https://github.com/Hackerpilot/Dscanner/blob/master/src/analysis/builtin_property_names.d

Re: Type Inference Bug?

On Friday, 21 November 2014 at 19:19:20 UTC, Daniel Murphy wrote: Furthermore, I'm starting to get very confused: enum sameTypes(T, U) = is(T: U) is(U: T); assert(sameTypes!(const int, immutable int)); //Ok, wtf? assert(sameTypes!(int, immutable int); //Ok, wtf? All of those types

Re: Type Inference Bug?

Meta wrote in message news:wkhobsfnumjpyyrpd...@forum.dlang.org... Yes, right, as they are POD value types. I'm not sure I like that, as it can't be guaranteed that T1 and T2 are the same type if is(T1: T2) is(T2: T1) are true... I will submit a bug report regarding my original issue,

Re: Type Inference Bug?

On Friday, 21 November 2014 at 07:40:31 UTC, Daniel Murphy wrote: It doesn't print anything for me. This code seems to have the desired effect: shared const int i; void main() { static if (is(typeof(i) : shared(U), U)) { //Prints const(int) pragma(msg, U); } } Hmm,

Re: Type Inference Bug?

Meta wrote in message news:tyfdmprlmreagrrnb...@forum.dlang.org... Hmm, do you know why is(typeof(i) == shared(U), U)) might fail? I wonder why : is required over ==... Doesn't the former check if T is a subtype of U, rather than check that they're the same type? I have no idea, I tried ==

Re: Type Inference Bug?

On Friday, 21 November 2014 at 15:29:05 UTC, Daniel Murphy wrote: but you could enforce exact type with something like if (typeof(i) == shared(U), U) is(shared(U) == typeof(i)) I'm assuming you meant if (typeof(i): shared(U), U) is(shared(U): typeof(i))).

Re: Type Inference Bug?

On Friday, 21 November 2014 at 07:40:31 UTC, Daniel Murphy wrote: It doesn't print anything for me. This code seems to have the desired effect: shared const int i; void main() { static if (is(typeof(i) : shared(U), U)) { //Prints const(int) pragma(msg, U); } } Now

Re: Type Inference Bug?

Meta wrote in message news:nwskxjncbwqndlkie...@forum.dlang.org... On Friday, 21 November 2014 at 15:29:05 UTC, Daniel Murphy wrote: but you could enforce exact type with something like if (typeof(i) == shared(U), U) is(shared(U) == typeof(i)) I'm assuming you meant if (typeof(i):

Re: Type Inference Bug?

Meta wrote in message news:szrhmjrinsymyihem...@forum.dlang.org... Now how about this one: alias Unshared(T: shared U, U) = U; pragma(msg, Unshared!(shared const int)); //Prints const(int) Does the `:` denote subtyping as well, or equality? I'm sure that Neither. IIRC it's something close

Re: Type Inference Bug?

Meta wrote in message news:wzczhiwokauvkkevt...@forum.dlang.org... shared const int i; static if (is(typeof(i) T == shared U, U)) { //Prints shared(const(int)) pragma(msg, U); } This seems like subtly wrong behaviour to me. If T == shared U, for some U, then shouldn't U be

Re: Template Instantiation Bug

On 11/4/14 4:48 PM, Walter Bright wrote: On 11/4/2014 9:51 AM, Jonathan Marler wrote: given the output of Transform, the compiler cannot deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE. To answer a question not asked, why doesn't the compiler see the

Re: Template Instantiation Bug

Steven Schveighoffer wrote in message news:m3bap5$khl$1...@digitalmars.com... https://issues.dlang.org/show_bug.cgi?id=1807 Hm.. interesting to note that Martin's suggestion has come to fruition, might this be revisited? Not really, templated aliases behave exactly the same as aliases in

Re: Template Instantiation Bug

On Tuesday, 4 November 2014 at 21:48:29 UTC, Walter Bright wrote: On 11/4/2014 9:51 AM, Jonathan Marler wrote: given the output of Transform, the compiler cannot deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE. To answer a question not asked, why doesn't

Re: Template Instantiation Bug

On 11/4/14 11:01 AM, Jonathan Marler wrote: In the past I don't get much response when I file a bug in BugZilla so I wanted to see if anyone could tell me anything about this issue in the forums. I believe a bug has already been created here: https://issues.dlang.org/show_bug.cgi?id=2372

Re: Template Instantiation Bug

On Tuesday, 4 November 2014 at 16:55:10 UTC, Steven Schveighoffer wrote: This is as designed. The reason is because the compiler cannot deduce *backwards* how to instantiate a template to get the right result. I ran into this a long time ago when porting Tango. Here is the counter-case:

Re: Template Instantiation Bug

Steven Schveighoffer wrote in message news:m3b0dd$6e0$1...@digitalmars.com... People have argued in the past that anything with a simple alias should be doable. I don't know if that's true or not, but I don't think it works today. There may be a bug report somewhere on it, I didn't search.

Re: Template Instantiation Bug

On 11/4/14 1:05 PM, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:m3b0dd$6e0$1...@digitalmars.com... People have argued in the past that anything with a simple alias should be doable. I don't know if that's true or not, but I don't think it works today. There may be a bug

Re: Template Instantiation Bug

On 11/4/2014 9:51 AM, Jonathan Marler wrote: given the output of Transform, the compiler cannot deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE. To answer a question not asked, why doesn't the compiler see the simple case and handle it? The problem is

Re: Template Instantiation Bug

On Tuesday, 4 November 2014 at 21:48:29 UTC, Walter Bright wrote: On 11/4/2014 9:51 AM, Jonathan Marler wrote: given the output of Transform, the compiler cannot deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE. To answer a question not asked, why doesn't

Re: function pointer bug?

Though, explicit reference to TestClass.instanceMethod is not a delegate. The delegate is constructed manually later in the code on attempt to call the method.

Re: function pointer bug?

I think I've got it figured out. In my original example, I added the following line inside the function-template, and the class-template: pragma(msg, typeof(T).stringof); in both cases, the (correct)result was a tuple of a function (void()) But, when it came time to retrieve the address

Re: function pointer bug?

On Tuesday, 28 October 2014 at 02:34:14 UTC, ketmar via Digitalmars-d wrote: On Tue, 28 Oct 2014 01:36:01 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: I have actually found a work around as well, which was to wrap the actual retrieval of the function address in a lambda,

Re: function pointer bug?

On Monday, 27 October 2014 at 22:17:25 UTC, bitwise wrote: This error seems like it may be related some how: enum index = __traits(getVirtualIndex, TestClass.instanceMethod); enum p = TestClass.classinfo.vtbl[index]; The above code will produce this error: Error: typeid(main.TestClass).vtbl

Re: function pointer bug?

On Tuesday, 28 October 2014 at 02:34:14 UTC, ketmar via Digitalmars-d wrote: On Tue, 28 Oct 2014 01:36:01 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: I have actually found a work around as well, which was to wrap the actual retrieval of the function address in a lambda,

Re: function pointer bug?

That being said, you only need to worry about any of this if you want to support virtual methods and have it invoke the actual overridden method, not the one you have saved through reflection. (For example, if Bar : Foo overrides foo, and you generated reflection info for Foo, it would call

Re: function pointer bug?

On 10/27/14 4:52 PM, bitwise wrote: quotes self Here is a better example, showing that virtual function pointers are available at compile time in C++. Essentially, I would expect my D code to function similarly, but it won't compile. class TestAddr { public: virtual void test() { cout

<    1   2   3   4   5   6   >