On Fri, 07 Jun 2013 17:01:27 +0200, Tyler Jameson Little <beatgammit@gmail.com> wrote:

> @nogc void foo() {} // #1
> @safe void foo() {}             // #2
>
> @nogc void baz() {
>      foo();
> }
>
> Which gets called when -safe is passed?

I'm not familiar with -safe, but in the example above #1 would be called, as
baz claims be @nogc, and thus that its callees are also @nogc. #1 fulfills
this requirement, #2 does not.

If in addition to @nogc baz was marked @safe, it would be a compile-time
error - there is no function foo that is both @safe and @nogc.

This is just like pure, @safe and nothrow today - if a function is pure
nothrow, it can not call a function that is only pure or only nothrow.

-- 
Simen

> What is the -safe option? I don't see it in DMD help.
>
> @safe is specified without @nogc, but calling function is @nogc, so I think that #1 should be chosen.

I pulled that from here: http://dlang.org/memory-safe-d.html

Maybe that's out of date?

On Sat, 08 Jun 2013 04:09:25 +0200, Tyler Jameson Little <beatgammit@gmail.com> wrote:

>> What is the -safe option? I don't see it in DMD help.
>>
>> @safe is specified without @nogc, but calling function is @nogc, so I think that #1 should be chosen.
>
> I pulled that from here: http://dlang.org/memory-safe-d.html
>
> Maybe that's out of date?

Would seem so. Safe D is activated with @safe, and the compiler switch
-safe gives an error message from the compiler.

If you want your entire module to be @safe, insert @safe: at the top of
the module.

-- 
Simen

On Saturday, 8 June 2013 at 07:10:29 UTC, Simen Kjaeraas wrote:
> On Sat, 08 Jun 2013 04:09:25 +0200, Tyler Jameson Little <beatgammit@gmail.com> wrote:
>
>>> What is the -safe option? I don't see it in DMD help.
>>>
>>> @safe is specified without @nogc, but calling function is @nogc, so I think that #1 should be chosen.
>>
>> I pulled that from here: http://dlang.org/memory-safe-d.html
>>
>> Maybe that's out of date?
>
> Would seem so. Safe D is activated with @safe, and the compiler switch
> -safe gives an error message from the compiler.
>
> If you want your entire module to be @safe, insert @safe: at the top of
> the module.

Then the documentation should be changed, or the feature implemented. I've never had cause to use it, so I never got around to checking it.

Which is correct, the documentation or the implementation?

On Sat, 08 Jun 2013 19:14:25 +0200, Tyler Jameson Little <beatgammit@gmail.com> wrote:

> On Saturday, 8 June 2013 at 07:10:29 UTC, Simen Kjaeraas wrote:
>> On Sat, 08 Jun 2013 04:09:25 +0200, Tyler Jameson Little <beatgammit@gmail.com> wrote:
>>
>>>> What is the -safe option? I don't see it in DMD help.
>>>>
>>>> @safe is specified without @nogc, but calling function is @nogc, so I think that #1 should be chosen.
>>>
>>> I pulled that from here: http://dlang.org/memory-safe-d.html
>>>
>>> Maybe that's out of date?
>>
>> Would seem so. Safe D is activated with @safe, and the compiler switch
>> -safe gives an error message from the compiler.
>>
>> If you want your entire module to be @safe, insert @safe: at the top of
>> the module.
>
> Then the documentation should be changed, or the feature implemented. I've never had cause to use it, so I never got around to checking it.
>
> Which is correct, the documentation or the implementation?

The implementation. I've filed a bug for the documentation:
http://d.puremagic.com/issues/show_bug.cgi?id=10297

-- 
Simen

On Saturday, 1 June 2013 at 20:20:56 UTC, Adam D. Ruppe wrote:
> So I'm still playing with this and just realized the TypeInfos that are manually written in the real druntime could just as easily be auto-generated.
>
> mixin(makeTypeInfo!(char[], ... more types as needed ... )());
>
> private string makeTypeInfo(T...)() {
>         if(__ctfe) { // this is here so we don't have runtime requirements of array append, etc, but can still use them in ctfe
>
>         string code;
>         foreach(t; T) {
>                 code ~= "class TypeInfo_" ~ t.mangleof ~ " : TypeInfo {
>                         override string toString() const { return \""~t.stringof~"\"; }
>                 }";
>         }
>         return code;
>
>         } else assert(0);
> }
>
>
>
> and so on for the other typeinfo methods. Or we could just copy/paste the typeinfos Walter wrote in the real druntime but meh.
>
> What I'm actually doing with most these is this:
>
> class TypeInfo_A : TypeInfo {}
> class TypeInfo_i : TypeInfo {}
> [etc...]
>
>
> So they are pretty much useless at runtime, but the compiler often outputs references to them, so if we don't have the definition, it won't actually link.
>
>
> But just thinking about runtime reflection, if we wanted to expand it, I say this is the way to go. Literally build the runtime code out of the compile time information.
>
> Currently, you can't do something like typeid(int).isIntegral(). There is no isIntegral function, and adding it means doing a lot of boring manual stuff to add.
>
> But with the mixin, we can just throw it in with three lines and be done with it.
>
>
> I might actually do that here, just because I can. On a -version switch, of course, so you can easily opt out of the fat implementation.

On Sunday, 9 June 2013 at 10:41:16 UTC, dam wrote:
> On Saturday, 1 June 2013 at 20:20:56 UTC, Adam D. Ruppe wrote:
>> So I'm still playing with this and just realized the TypeInfos that are manually written in the real druntime could just as easily be auto-generated.
>>
>> mixin(makeTypeInfo!(char[], ... more types as needed ... )());
>>
>> private string makeTypeInfo(T...)() {
>>        if(__ctfe) { // this is here so we don't have runtime requirements of array append, etc, but can still use them in ctfe
>>
>>        string code;
>>        foreach(t; T) {
>>                code ~= "class TypeInfo_" ~ t.mangleof ~ " : TypeInfo {
>>                        override string toString() const { return \""~t.stringof~"\"; }
>>                }";
>>        }
>>        return code;
>>
>>        } else assert(0);
>> }
>>
>>
>>
>> and so on for the other typeinfo methods. Or we could just copy/paste the typeinfos Walter wrote in the real druntime but meh.
>>
>> What I'm actually doing with most these is this:
>>
>> class TypeInfo_A : TypeInfo {}
>> class TypeInfo_i : TypeInfo {}
>> [etc...]
>>
>>
>> So they are pretty much useless at runtime, but the compiler often outputs references to them, so if we don't have the definition, it won't actually link.
>>
>>
>> But just thinking about runtime reflection, if we wanted to expand it, I say this is the way to go. Literally build the runtime code out of the compile time information.
>>
>> Currently, you can't do something like typeid(int).isIntegral(). There is no isIntegral function, and adding it means doing a lot of boring manual stuff to add.
>>
>> But with the mixin, we can just throw it in with three lines and be done with it.
>>
>>
>> I might actually do that here, just because I can. On a -version switch, of course, so you can easily opt out of the fat implementation.