Re: Is this a bug?

On Thursday, 16 March 2023 at 04:31:11 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote: [...] Correction. With or without comments, mostly it doesn't compile, occasionally it does! I have no idea.

Re: Is this a bug?

On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote: [...] Oops, the above code compiles, because I added comments!!! Now this really doesn't compile: ```D struct

Re: Is this a bug?

On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote: [...] Oops, the above code compiles, because I added comments!!! Now this really doesn't compile: ```D struct Matrix(S, size_t M, size_t N) { } alias Vec3(S) = Matrix!(S,

Re: Is this a bug?

On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote: ```D struct Matrix(S, size_t M, size_t N) { } alias Vec3(S) = Matrix!(S, 3, 1); void main() { import std.stdio; writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias` `S` is defined here writeln(is(Matrix!(float, 3,

Re: Is is a Bug or just me?

On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote: Hi d community, I got a strange behavior since dmd 2.090 (dmd 2.089 is the last working version). See this reduced code: https://run.dlang.io/is/yoyHXC I would expect that foo() returns 2. My guess in foo is: The return value of val is

Re: Is is a Bug or just me?

On Friday, 8 May 2020 at 14:32:33 UTC, kinke wrote: On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote: Now I am unsure if this is a bug or an undefined behavior that I don't know. This is a regression, and a potentially pretty bad one, so thx for tracking it down! If this is a bug, then

Re: Is is a Bug or just me?

On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote: Now I am unsure if this is a bug or an undefined behavior that I don't know. This is a regression, and a potentially pretty bad one, so thx for tracking it down! If this is a bug, then I don't know how to call it for the bug tracker.

Re: Is it a bug in std.getopt.config.stopOnFirstNonOption?

On 08/16/2019 02:07 PM, Andrey Zherikov wrote: But: - if I change line (1) to `auto args = ["app", "--foo", "foo", "--bar", "bar"];` then this code works. - if I remove line (2) then this code works. Yes, it's a bug. Another workaround--which I haven't tested to see whether produces the

Re: Undescriptive linker error. (bug?)

On Friday, 5 April 2019 at 22:08:50 UTC, Adam D. Ruppe wrote: Weird combination of cases that maybe should be illegal. It errors with the highly descriptive errormessage: app.obj(app) Error 42: Symbol Undefined __D8mymodule3BarFZ3fooMFZCQx3Foo Error: linker exited with status 1

Re: Undescriptive linker error. (bug?)

On Friday, 5 April 2019 at 21:59:35 UTC, Sjoerd Nijboer wrote: Foo Bar() { Foo foo(); It looks like the compiler is treating that as a function prototype without a body (that just happens to be nested in another function). return foo; And then, this foo is given the

Re: Is this a bug? +goto

On Thursday, 8 November 2018 at 09:34:34 UTC, Michelle Long wrote: What I am talking about is about an obvious error... OK, so here are your code slightly modified: void main(){ int i; W: if(i==0) goto Q; int x; Q: i++; if(i==1) goto W; writeln("a");

Re: Is this a bug? +goto

On Thursday, 8 November 2018 at 10:31:31 UTC, Jonathan M Davis wrote: On Thursday, November 8, 2018 2:34:34 AM MST Michelle Long via Digitalmars- d-learn wrote: Obviously, but that is not the case I mentioned. You can assume that I know how scopes work. No need to assume everyone that shows

Re: Is this a bug? +goto

On Thursday, November 8, 2018 2:34:34 AM MST Michelle Long via Digitalmars- d-learn wrote: > Obviously, but that is not the case I mentioned. You can assume > that I know how scopes work. No need to assume everyone that > shows two cases that you have to bring up an unrelated case as a > potential

Re: Is this a bug? +goto

On Thursday, 8 November 2018 at 06:56:14 UTC, Jonathan M Davis wrote: On Wednesday, November 7, 2018 10:50:29 PM MST Michelle Long via Digitalmars-d-learn wrote: On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis wrote: > On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long

Re: Is this a bug? +goto

On Wednesday, November 7, 2018 10:50:29 PM MST Michelle Long via Digitalmars-d-learn wrote: > On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis > > wrote: > > On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via > > > > Digitalmars- d-learn wrote: > >> Don't let their

Re: Is this a bug? +goto

On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis wrote: On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via Digitalmars- d-learn wrote: Don't let their psychobabble fool you. They are wrong and you were right from the start. ... Case A: { if (true) goto X;

Re: Is this a bug? +goto

On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via Digitalmars- d-learn wrote: > Don't let their psychobabble fool you. They are wrong and you > were right from the start. ... > Case A: > { > if (true) goto X; > int x; > } > X: > > > Case B: > { > if (true) goto X; >

Re: Is this a bug? +goto

On Wednesday, 7 November 2018 at 20:03:47 UTC, Michelle Long wrote: Case A: int x; { if (true) goto X; //int x; } ~x; X: That is not "Case A". This one is: { if (true) goto X; T x; X: } // x.__dtor That should error as an easy cop-out, nothing wrong with that approach.

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 13:53:41 UTC, MatheusBN wrote: On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis wrote: On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn wrote: On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis wrote: >> And I

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis wrote: On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn wrote: On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis wrote: >> And I found a bit strange that in such code, since "x" is >> never

Re: Is this a bug? +goto

On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn wrote: > On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis > > wrote: > >> And I found a bit strange that in such code, since "x" is > >> never used, why it isn't skipped. > > > > It's skipped right over. The

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 01:05:04 UTC, Neia Neutuladh wrote: In C++, if you skip over `int i = 10;` it's an error, but not if you skip over `int i;`. In fact I agree with that rule more than the D one to be honest. Since It isn't initialized and never used, I think a warning should be

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 01:04:46 UTC, Stanislav Blinov wrote: ...Even if you don't see any explicit use, it doesn't mean the compiler doesn't see an implicit one. Sorry I don't think that I follow that. How a compiler could see an use when it's not being used/invoked on a program like

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis wrote: And I found a bit strange that in such code, since "x" is never used, why it isn't skipped. It's skipped right over. The goto jumps out of the scope, and the line with int x; is never run. In fact, if you compile with -w

Re: Is this a bug? +goto

On Monday, November 5, 2018 5:33:56 PM MST MatheusBN via Digitalmars-d-learn wrote: > On Tuesday, 6 November 2018 at 00:14:26 UTC, Jonathan M Davis > > wrote: > > On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via > > > > Digitalmars-d-learn wrote: > >> Hi, > >> > >> I posted this in

Re: Is this a bug? +goto

On Tue, 06 Nov 2018 00:33:56 +, MatheusBN wrote: > Just to be clear, when you say "x exists at the label Q", you mean at > the same scope, right? The same or an outer scope. It's also invalid to write: goto Y; { int x; { Y: } } > That's interesting but a bit confusing isn't? > >

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 00:38:01 UTC, MatheusBN wrote: On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov wrote: But here it's fine: void main(){ { goto Q; S x; } // <--- Q: writeln("a"); } because goto jumps over both initialization

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov wrote: But here it's fine: void main(){ { goto Q; S x; } // <--- Q: writeln("a"); } because goto jumps over both initialization *and* destruction, i.e. neither would even be performed. I see

Re: Is this a bug? +goto

On Tuesday, 6 November 2018 at 00:14:26 UTC, Jonathan M Davis wrote: On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via Digitalmars-d-learn wrote: Hi, I posted this in another thread but without any response. This code: void main(){ goto Q; int x; Q:

Re: Is this a bug? +goto

On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via Digitalmars-d-learn wrote: > Hi, > > I posted this in another thread but without any response. > > This code: > > void main(){ > goto Q; > int x; > Q: > writeln("a"); > } > > Gives me this error: "source_file.d(4):

Re: Is this a bug? +goto

On Monday, 5 November 2018 at 23:54:59 UTC, MatheusBN wrote: Hi, I posted this in another thread but without any response. This code: void main(){ goto Q; int x; Q: writeln("a"); } Gives me this error: "source_file.d(4): Error: goto skips declaration of variable

Re: Is this a bug?

On Tuesday, 16 October 2018 at 13:09:34 UTC, Steven Schveighoffer wrote: On 10/15/18 4:36 PM, Márcio Martins wrote: [...] Hm... didn't realize that. It seems to me like an odd limitation, but I can see how it's ambiguous. The solution is to double-template: template incx(Args...) {

Re: Is this a bug?

On 10/15/18 4:36 PM, Márcio Martins wrote: On Monday, 15 October 2018 at 16:46:34 UTC, Steven Schveighoffer wrote: On 10/15/18 12:40 PM, Márcio Martins wrote: import std.stdio; void incx(T, Args...)(ref T t) { ++t.x; } static struct Test(T) { T x; } void main() { Test!uint t;

Re: Is this a bug?

You can simply group them: t.on!( handlers!( "abc", { writeln("abc"); }, "cde", { writeln("cde"); } ) ); handlers!( "abc", { writeln("abc"); }, "cde", { writeln("cde"); } ).bind(t);

Re: Is this a bug?

On Tuesday, 16 October 2018 at 02:13:21 UTC, Ali Çehreli wrote: On 10/15/2018 01:36 PM, Márcio Martins wrote: > Considering that the declaration is legal, and that the template > parameter deduction works when Args.length == 0, but stops working when > Args.length > 0. For deduction to work,

Re: Is this a bug?

On 10/15/2018 01:36 PM, Márcio Martins wrote: > Considering that the declaration is legal, and that the template > parameter deduction works when Args.length == 0, but stops working when > Args.length > 0. For deduction to work, there must be function arguments. So, just add Args to the

Re: Is this a bug?

On Monday, 15 October 2018 at 16:46:34 UTC, Steven Schveighoffer wrote: On 10/15/18 12:40 PM, Márcio Martins wrote: import std.stdio; void incx(T, Args...)(ref T t) {     ++t.x; } static struct Test(T) {     T x; } void main() {     Test!uint t;     t.incx();   // works    

Re: Is this a bug?

On 10/15/18 12:46 PM, Steven Schveighoffer wrote: Did you mean incx!(T, 1, 2, 3)(t) ? Sorry, incx!(Test!uint, 1, 2, 3)(t) -Steve

Re: Is this a bug?

On 10/15/18 12:40 PM, Márcio Martins wrote: import std.stdio; void incx(T, Args...)(ref T t) {     ++t.x; } static struct Test(T) {     T x; } void main() {     Test!uint t;     t.incx();   // works     t.incx!();  // works     incx(t);    // works    

Re: is this a bug ? mixin template static function missing!

On Friday, 10 August 2018 at 12:05:52 UTC, Simen Kjærås wrote: On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote: If you try the same without the mixin template, you'll see that it doesn't work: struct Test { extern(C) pragma(crt_constructor) static void init(){ // work

Re: is this a bug ? mixin template static function missing!

On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote: I think the static extern(C) nested function should just work like global extern(C) function. DMD still report missing symbols. Or I am wrong about this ? template G(){ static extern(C) pragma(crt_constructor) void

Re: is this a bug ? mixin template static function missing!

On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote: On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote: Filed a bug: https://issues.dlang.org/show_bug.cgi?id=19153 template G(){ pragma(crt_constructor) static extern(C) void init(){} } void main(){ mixin G!(); //

Re: is this a bug ? mixin template static function missing!

On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote: On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote: The correct behavior would be for the compiler to show the latter error message for a mixin'd function as well. Filed a bug:

Re: is this a bug ? mixin template static function missing!

On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote: #!/usr/bin/env rdmd import core.stdc.stdio; template G(size_t line = __LINE__, A...){ int i = 3; static extern(C) pragma(crt_constructor) void init2(){ printf("init: %d\n", line); } }

Re: is this a bug with writeln / std.algorithm.remove?

On Friday, 16 February 2018 at 13:57:07 UTC, Steven Schveighoffer wrote: You have a pretty good minimal test, put that in bugzilla along with the forum thread link and all the info we know. Mark it as a dmd bug, regression, along with the version where it regressed (2.076.1), and I would tag

Re: is this a bug with writeln / std.algorithm.remove?

On 2/16/18 8:51 AM, arturg wrote: On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer wrote: Strictly speaking, this is not necessarily proof that it's in phobos, there could have been changes elsewhere that cause one of the conditions to fail. However, testing this out, I

Re: is this a bug with writeln / std.algorithm.remove?

On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer wrote: Strictly speaking, this is not necessarily proof that it's in phobos, there could have been changes elsewhere that cause one of the conditions to fail. However, testing this out, I found something very weird. If you

Re: is this a bug with writeln / std.algorithm.remove?

On 2/16/18 8:16 AM, bauss wrote: On Friday, 16 February 2018 at 13:08:09 UTC, bauss wrote: On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote: On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote: this code fails to compile:     void delegate(void*) dg;     void delegate(void*)[]

Re: is this a bug with writeln / std.algorithm.remove?

On Friday, 16 February 2018 at 13:08:09 UTC, bauss wrote: On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote: On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote: this code fails to compile: void delegate(void*) dg; void delegate(void*)[] dgs = [dg, dg, dg];

Re: is this a bug with writeln / std.algorithm.remove?

On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote: On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote: this code fails to compile: void delegate(void*) dg; void delegate(void*)[] dgs = [dg, dg, dg]; dgs.writeln; dgs.remove(1).writeln(); if you comment out

Re: is this a bug with writeln / std.algorithm.remove?

On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote: this code fails to compile: void delegate(void*) dg; void delegate(void*)[] dgs = [dg, dg, dg]; dgs.writeln; dgs.remove(1).writeln(); if you comment out dgs.writeln; it works as expected, it works if you use other types

Re: if (int bar = .. bug or some thing

On Tuesday, 31 October 2017 at 04:27:27 UTC, Joel wrote: Ok, thanks guys. why not throw in some UFCS too...just because you can ;-) import std.stdio; void main() { int foo; if (foo.bar != 0) // would be nice if I could do: (int foo.bar != 0) { throw new

Re: if (int bar = .. bug or some thing

Ok, thanks guys.

Re: if (int bar = .. bug or some thing

On Tuesday, 31 October 2017 at 04:08:12 UTC, Joel wrote: if (int bar = foo() != 0) { Not a bug, but I do think it is an iffy design. That is more like: int bar; if(bar = (foo() != 0)) so the foo != 0 is evaluated first, which ends up being boolean true or false, then THAT

Re: if (int bar = .. bug or some thing

On Tuesday, October 31, 2017 04:08:12 Joel via Digitalmars-d-learn wrote: > The following code assert fails (bar == 1, not -10!). I've wasted > a bit of time because of this happening. > > void main() { > if (int bar = foo() != 0) { > assert(bar == -10); > } > } > > auto foo() { >

Re: C++ namespace mangling: bug or me being stupid?

On Tuesday, 28 March 2017 at 16:30:19 UTC, kinke wrote: That's a mangling compression scheme (possibly tunable via gcc options), from https://github.com/gchatelet/gcc_cpp_mangling_documentation: To save space a compression scheme is used where symbols that appears multiple times are then

Re: C++ namespace mangling: bug or me being stupid?

On Tuesday, 28 March 2017 at 16:30:19 UTC, kinke wrote: That's a mangling compression scheme (possibly tunable via gcc options), from https://github.com/gchatelet/gcc_cpp_mangling_documentation: To save space a compression scheme is used where symbols that appears multiple times are then

Re: C++ namespace mangling: bug or me being stupid?

That's a mangling compression scheme (possibly tunable via gcc options), from https://github.com/gchatelet/gcc_cpp_mangling_documentation: To save space a compression scheme is used where symbols that appears multiple times are then substituted by an item from the sequence : S_, S0_, S1_, S2_,

Re: Is this a bug ?

On 10/21/2016 06:55 PM, Basile B. wrote: This very simple stuff: class Item { alias children this; Item[] children; void populate() { children ~= new Item; assert(children.length == 1); } } void main() { Item root = new Item; root.populate; } leads

Re: Is this a bug ?

On 7/12/16 1:31 AM, Chang Long wrote: On Tuesday, 12 July 2016 at 04:38:42 UTC, Chang Long wrote: test.d = template newType(size_t N){ class NewType { enum Type = N ; } } just find it should be this: template newType(size_t N){

Re: local const functions - bug ?

On Sunday, 10 July 2016 at 07:20:29 UTC, Meta wrote: On Friday, 8 July 2016 at 09:01:10 UTC, Marc Schütz wrote: `foo()` is effectively a delegate, therefore `const` applies to the context. AFAIK const on a function can only ever refer to the `this` pointer, but there is no `this` pointer.

Re: Is this a bug ?

On Tuesday, 12 July 2016 at 04:38:42 UTC, Chang Long wrote: test.d = template newType(size_t N){ class NewType { enum Type = N ; } } just find it should be this: template newType(size_t N){ class NewType {

Re: local const functions - bug ?

On Sunday, 10 July 2016 at 07:20:29 UTC, Meta wrote: On Friday, 8 July 2016 at 09:01:10 UTC, Marc Schütz wrote: `foo()` is effectively a delegate, therefore `const` applies to the context. AFAIK const on a function can only ever refer to the `this` pointer, but there is no `this` pointer.

Re: local const functions - bug ?

On Friday, 8 July 2016 at 09:01:10 UTC, Marc Schütz wrote: `foo()` is effectively a delegate, therefore `const` applies to the context. AFAIK const on a function can only ever refer to the `this` pointer, but there is no `this` pointer.

Re: local const functions - bug ?

On Thursday, 7 July 2016 at 15:02:29 UTC, Jonathan M Davis wrote: On Thursday, July 07, 2016 10:33:39 Basile B. via Digitalmars-d-learn wrote: this compiles without error: struct Foo { int i; void bar() { void foo() const { i = 1; }

Re: local const functions - bug ?

On Thursday, July 07, 2016 10:33:39 Basile B. via Digitalmars-d-learn wrote: > this compiles without error: > > > struct Foo > { > int i; > void bar() > { > void foo() const > { > i = 1; > } > foo; > } > } > > In this case

Re: local const functions - bug ?

On Thursday, 7 July 2016 at 12:24:08 UTC, Edwin van Leeuwen wrote: On Thursday, 7 July 2016 at 10:33:39 UTC, Basile B. wrote: this compiles without error: struct Foo { int i; void bar() { void foo() const { i = 1; } foo; } } In this

Re: local const functions - bug ?

On Thursday, 7 July 2016 at 10:33:39 UTC, Basile B. wrote: this compiles without error: struct Foo { int i; void bar() { void foo() const { i = 1; } foo; } } In this case "const" seems to be a noop. Do you think it's a bug ?

Re: local const functions - bug ?

On 07/07/2016 12:33 PM, Basile B. wrote: Do you think it's a bug ? Yes.

Re: Is this a bug?

On Saturday, April 16, 2016 00:28:46 ag0aep6g via Digitalmars-d-learn wrote: > On 15.04.2016 20:55, Eric wrote: > > 13 class C : const (I!(J)) > > I think this const is ignored by the compiler. It's definitely ignored, and I'd argue that it's a bug in the compiler that it's even accepted.

Re: Is this a bug?

On 15.04.2016 20:55, Eric wrote: 13 class C : const (I!(J)) I think this const is ignored by the compiler. 15F!(J) m; A little tip: You can omit the parentheses of template instantiations when the argument is a single identifier. That is, `F!(J)` can be written as `F!J`.

Re: Is this a bug?

On Friday, 15 April 2016 at 18:28:58 UTC, Eric wrote: line 6 can be fixed like this: "const I!(J) i = a;" Now if I can just figure out how to fix line 15... This works: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 const (I!(J)) i = a; 7 } 8

Re: Is this a bug?

On Friday, 15 April 2016 at 18:22:02 UTC, Eric wrote: On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote: On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { }

Re: Is this a bug?

On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote: On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { } 10 11 class F(V) if (is(V : I!(V))) { } 12 13

Re: Is this a bug?

On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { } 10 11 class F(V) if (is(V : I!(V))) { } 12 13 class C : I!(J) 14 { 15 F!(J) m; 16 } The above

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote: IMO one shouldn't be able to take the reference of a tuple, to ensure that it can be kept in registers. No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote: When faced with a judgment call like this, we really ought to err on the side of maintaining backwards compatibility - especially since this does not preclude adding a separate by-value version of `Tuple.slice`, as well. It was

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 06:22:55 UTC, Marco Leise wrote: As mentioned I never used the feature myself and wont vote for one or the other. Three people with no source code to exemplify current use of .slice! is indeed not much to base decisions on... The mere fact that all I had to do

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote: So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and arrays? Some key common qualities for a tuple: 1. They are primarily used

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote: No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this. If you

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 11:38:14 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote: No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote: So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote: I suggest lobbying for proper builtin tuple support. Built-in tuple support would be great (although to my mind, mostly because the current syntax is clunky). But that is a long-term goal, and `Tuple.slice` is corrupting

Re: Is this a bug in std.typecons.Tuple.slice?

On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote: [...] `Tuple.slice` is corrupting data *right now*. Some sort of short-term fix should be merged in the next release of D. +1

Re: Is this a bug in std.typecons.Tuple.slice?

Am Tue, 09 Feb 2016 00:38:10 + schrieb tsbockman : > On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: > > What I like most about your proposal is that it doesn't break > > any existing code that wasn't broken before. That can't be > > emphasized

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: What I like most about your proposal is that it doesn't break any existing code that wasn't broken before. That can't be emphasized enough. Although I wish more than 3 people had voted in my poll, two of them did claim to need

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 11:02:37 + schrieb tsbockman : > On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: > > I think we should add a static assert to slice to ensure that > > the current implementation is not used in a case where the > > alignment

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote: We should start a new thread in "General" to ask whether people care about the `ref`-ness of `Tuple` slices is really the deciding factor. I made a poll: http://forum.dlang.org/post/inswmiscuqirkhfql...@forum.dlang.org

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: I understand that. We just have a different perspective on the problem. Your priorities: - don't break what's not broken - .slice! lends on opSlice and should return by ref My priorities: - type of .slice! should be as if

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: Why do I insist on the return type? Because surprisingly simple code breaks if it doesn't match. Not everything can be covered by runtime conversions in D. It still took me a while to come up with something obvious:

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote: On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: I understand that. We just have a different perspective on the problem. Your priorities: - don't break what's not broken - .slice! lends on opSlice and should return by

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 07:57:08 + schrieb tsbockman : > On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: > > I don't want to sound dismissive, but when that thought came > > to my mind I considered it unacceptable that the type of > > Tuple!(int, bool,

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: [...] I should also point out that, since there is no way to actually find out whether anyone is using the `ref`-ness of the return type in the wild, the approach that you and Saurabh Das are taking really ought to include

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: I don't want to sound dismissive, but when that thought came to my mind I considered it unacceptable that the type of Tuple!(int, bool, string).slice(1, 3) would be something different than Tuple!(bool, string). In your case

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: I think we should add a static assert to slice to ensure that the current implementation is not used in a case where the alignment doesn't match. This is better than failing without any warning. If we pursue the deprecation

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 08:01:20 UTC, tsbockman wrote: On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: [...] I should also point out that, since there is no way to actually find out whether anyone is using the `ref`-ness of the return type in the wild, the approach

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 04:28:17 + schrieb tsbockman : > On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: > >> > 1. Removing 'ref' from the return type > > > > Must happen. 'ref' only worked because of the reinterpreting > > cast which doesn't work in

Re: Is this a bug in std.typecons.Tuple.slice?

Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : > On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: > [...] > > Apologies for spamming. This is an improved implementation: > > @property > Tuple!(sliceSpecs!(from, to)) slice(size_t

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: > 1. Removing 'ref' from the return type Must happen. 'ref' only worked because of the reinterpreting cast which doesn't work in general. This will change the semantics. Now the caller of 'slice' will deal with a whole new copy

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : [...] That is enlightening. I have updated the PR at https://github.com/D-Programming-Language/phobos/pull/3975 to incorporate these changes.

  1   2   3   >