Re: Type Inference in @safe unittests

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 8/22/17 5:44 PM, jmh530 wrote: On Tuesday, 22 August 2017 at 18:25:31 UTC, Steven Schveighoffer wrote: @safe void main() { struct Foo { int foo(int i, string s) @safe { return 0; } double foo2(string s) @safe { return 0; } } printMemberTypes!(Foo); } The

Re: Type Inference in @safe unittests

2017-08-22 Thread jmh530 via Digitalmars-d-learn
On Tuesday, 22 August 2017 at 18:25:31 UTC, Steven Schveighoffer wrote: @safe void main() { struct Foo { int foo(int i, string s) @safe { return 0; } double foo2(string s) @safe { return 0; } } printMemberTypes!(Foo); } The surprising part to me is that

Re: Type Inference in @safe unittests

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 8/22/17 2:19 PM, jmh530 wrote: Yeah, this happens with @safe main also (below), but not for more regular local blocks. Anyway, I found it very confusing as that's not how I assumed @safe applied to unittests or main worked. @safe void main() { struct Foo { int foo(int i,

Re: Type Inference in @safe unittests

2017-08-22 Thread jmh530 via Digitalmars-d-learn
On Tuesday, 22 August 2017 at 16:27:05 UTC, Jonathan M Davis wrote: Well, templates aren't the only case where we have attribute inference anymore (e.g. auto return functions have it), and I'm pretty sure that there have been several requests for fixing issues regards to local declarations

Re: Type Inference in @safe unittests

2017-08-22 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, August 22, 2017 16:11:11 jmh530 via Digitalmars-d-learn wrote: > I'm not sure if this is a bug or not. > > I was playing around with printing out some member types with > unittests and I was noticing some strange results when they were > in @safe unittests rather than normal unittests.

Type Inference in @safe unittests

2017-08-22 Thread jmh530 via Digitalmars-d-learn
I'm not sure if this is a bug or not. I was playing around with printing out some member types with unittests and I was noticing some strange results when they were in @safe unittests rather than normal unittests. The first one prints out what I would expect, but the @safe unittest puts @safe