On Friday, 10 February 2017 at 04:02:17 UTC, Era Scarecrow wrote:
> On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow wrote:
>> Seems the built in Date class wasn't the same as the Sql.Date that was being used (but had the same name). Apparently it took like 2 hours to figure out what was going on.
>
>  Oh right forgot to mention one important detail. In Java the program compiled without errors; It was when it was trying to be used that it would crash unexpectedly. Refusing to compile is slightly better than crashing unexpectedly later.

I saw it happen with D as well: everything compiles, everything is
fine, and suddenly segfault. The issue was caused by template argument, two
modules with the same name, but from different packages (think `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
somewhere in the middle of the callstack which casted the first template argument to the second one, where the `myalib`'s foo was casted to `myblib`'s interface.

Worse of all, `myalib` and `myblib` were just mentioned in the imports,
far away from the call site.

Am 09.02.2017 um 22:44 schrieb Daniel Kozak via Digitalmars-d:
> Dne 9.2.2017 v 22:28 Sönke Ludwig via Digitalmars-d napsal(a):
>
>> Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
>>> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
>>> (Path file, bool silent_fail = false) is not callable using argument
>>> types (Path, bool)
>>>
>>> WTF?
>>
>> Must be caused by Path meaning two different type definitions. The
>> most likely cause is that by default the DUB sources use their own
>> version of Path, while if vibe.d is available in the dependency graph,
>> they will use the ones defined there instead.
>>
>> But the error message is indeed awful.
> Yes, btw it is impossible to build https://github.com/dlang/dub-registry
> right now because of this

Thanks for the notice, I've committed a fix for DUB 1.2.1

On 2/10/2017 4:41 AM, Nemanja Boric wrote:
> I saw it happen with D as well: everything compiles, everything is
> fine, and suddenly segfault. The issue was caused by template argument, two
> modules with the same name, but from different packages (think
> `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
> somewhere in the middle of the callstack which casted the first template
> argument to the second one, where the `myalib`'s foo was casted to `myblib`'s
> interface.

That's why such casts are not allowed in @safe code.

On Fri, 10 Feb 2017 12:32:19 -0800, Walter Bright wrote:

> On 2/10/2017 4:41 AM, Nemanja Boric wrote:
>> I saw it happen with D as well: everything compiles, everything is fine, and suddenly segfault. The issue was caused by template argument, two modules with the same name, but from different packages (think `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast somewhere in the middle of the callstack which casted the first template argument to the second one, where the `myalib`'s foo was casted to `myblib`'s interface.
> 
> That's why such casts are not allowed in @safe code.

I'm a bit surprised by that. In @system code, you can cast, and it results in a null pointer. A well-known value. Just like using an uninitialized variable. And @safe doesn't stop you from using uninitialized variables.

On Saturday, 11 February 2017 at 01:14:03 UTC, Chris Wright wrote:
> And @safe doesn't stop you from using uninitialized variables.

Yes it does, for pointers anyway

void main() @safe
{
	int[] a = void;
}

/d296/f663.d(3): Error: variable f663.main.a void initializers for pointers not allowed in safe functions

On 2/10/2017 5:14 PM, Chris Wright wrote:
> On Fri, 10 Feb 2017 12:32:19 -0800, Walter Bright wrote:
>
>> On 2/10/2017 4:41 AM, Nemanja Boric wrote:
>>> I saw it happen with D as well: everything compiles, everything is
>>> fine, and suddenly segfault. The issue was caused by template argument,
>>> two modules with the same name, but from different packages (think
>>> `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
>>> somewhere in the middle of the callstack which casted the first
>>> template argument to the second one, where the `myalib`'s foo was
>>> casted to `myblib`'s interface.
>>
>> That's why such casts are not allowed in @safe code.
>
> I'm a bit surprised by that. In @system code, you can cast, and it results
> in a null pointer. A well-known value.

It depends on just what is being cast. If you're casting an interface to an Object, it is not allowed in @safe code because not all interfaces are Objects, and this is not reliably detectable at runtime.


> And @safe doesn't stop you from using uninitialized variables.

As shown, it does.

On Fri, 10 Feb 2017 21:19:37 -0800, Walter Bright wrote:
> On 2/10/2017 5:14 PM, Chris Wright wrote:
>> And @safe doesn't stop you from using uninitialized variables.
> 
> As shown, it does.

Default-initialized variables, sorry.

I don't see what's less safe about

  cast(MyInterface)new Object

than

  cast(MyInterface)null

The only difference is that there is a runtime call in between in the first example. And we'll get a similar runtime call with similar guarentees if it's instead

  cast(MyClass)new Object

Except this version is accepted in @safe code.

It seems inconsistent, and I'm wondering what the reasoning behind it is. The error message doesn't offer a way to reach an explanation.

On Friday, 10 February 2017 at 03:07:28 UTC, Adam D. Ruppe wrote:
> On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow
>>  In cases like these i really wish the structure of the class/struct had a hash or something (based on source or struct layout or something)
>
> They do have different full names, which includes the module name and uniquely differentiates them. The compiler knows it too, just isn't smart enough to actually display it in times like this.

The compiler actually has no brains, it's the people that program the compiler that you have to look at. Either they have no brains or are too lazy to care. After all, it's not their time that gets wasted.

On 2/10/2017 9:42 PM, Chris Wright wrote:
> On Fri, 10 Feb 2017 21:19:37 -0800, Walter Bright wrote:
>> On 2/10/2017 5:14 PM, Chris Wright wrote:
>>> And @safe doesn't stop you from using uninitialized variables.
>>
>> As shown, it does.
>
> Default-initialized variables, sorry.
>
> I don't see what's less safe about
>
>   cast(MyInterface)new Object

It's the other way around that's unsafe - casting an interface to an Object.

On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote:
> not all interfaces are Objects

Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object.