May 16, 2019
On Thursday, 16 May 2019 at 05:22:42 UTC, Seb wrote:
> Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too.

Well, it's an inherent property of DIP1000 to not compile code that previously compiled. Though safety of tupleof shouldn't depend on DIP1000.
May 16, 2019
On Thursday, 16 May 2019 at 10:03:42 UTC, Kagamin wrote:
> On Thursday, 16 May 2019 at 05:22:42 UTC, Seb wrote:
>> Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too.
>
> Well, it's an inherent property of DIP1000 to not compile code that previously compiled. Though safety of tupleof shouldn't depend on DIP1000.

Well, here's the full discussion:

https://github.com/dlang/dmd/pull/8035
May 16, 2019
On 5/15/2019 6:05 PM, H. S. Teoh wrote:
> Gah, so apparently .hashOf is a gigantic overload set of *21* different
> overloads, so this is not really "truly" reduced. =-O

I've often thought that Phobos excessively overused overloading. And you're quite right, it's a chore figuring out which one is the culprit.

What I do is change the name(s) to .hashOfx so it won't be picked, then one can figure out which one is selected through a process of elimination. Or insert:

    pragma(msg, __LINE__);

statements in each one.
May 16, 2019
On Thu, May 16, 2019 at 10:09:38AM -0700, Walter Bright via Digitalmars-d-announce wrote:
> On 5/15/2019 6:05 PM, H. S. Teoh wrote:
> > Gah, so apparently .hashOf is a gigantic overload set of *21* different overloads, so this is not really "truly" reduced. =-O
> 
> I've often thought that Phobos excessively overused overloading.

This is in druntime.


> And you're quite right, it's a chore figuring out which one is the culprit.

More and more, I'm becoming convinced that this sort of usage of function overloading is an anti-pattern.  It should instead be written as something like this:

	size_t hashOf(T)(T* arg)
		// N.B.: no sig constraints: because we expect to be
		// able to hash anything.
	{
		static if (is(T == struct))
			return hashOfStruct(arg);
		else static if (is(T == U[], U))
			return hashOfArray(arg);
		...
		else
			static assert(0, "Hash of " ~ T.stringof ~ " not supported");
	}

The sig constraints, or lack thereof, ought to reflect the *logical* set of acceptable types, not necessarily the actual set supported by the implementation. I.e., hashOf logically *should* support all types, but maybe the current implementation doesn't (yet) support a particular corner case; so it should still accept the type, but emit an error explaining the implementation deficiency in a static assert, rather than just passing the buck back to the compiler which then spews forth a text wall of incomprehensible gibberish of how all 21 overloads failed to match.


> What I do is change the name(s) to .hashOfx so it won't be picked, then one can figure out which one is selected through a process of elimination. Or insert:
> 
>     pragma(msg, __LINE__);
> 
> statements in each one.

Good idea. But looks like Nicholas has already done the heavy lifting for us.  :-D


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com
May 16, 2019
On 5/16/2019 10:24 AM, H. S. Teoh wrote:
> More and more, I'm becoming convinced that this sort of usage of
> function overloading is an anti-pattern.  It should instead be written
> as something like this:

I agree. And there at least you can find all the uses.

> Good idea. But looks like Nicholas has already done the heavy lifting
> for us.  :-D

The problem will come up again.

May 17, 2019
On Wednesday, 15 May 2019 at 08:32:09 UTC, Walter Bright wrote:
> On 5/15/2019 12:21 AM, Dukc wrote:
>> Could be worth a try even without docs, but in the long run we definitely need some explaining.
>
> True, but I've tried fairly hard with the error messages. Please post your experiences with them.

Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you.

https://forum.dlang.org/post/laqjadtwrsdhdrqokryx@forum.dlang.org
May 17, 2019
On Friday, 17 May 2019 at 04:50:52 UTC, Meta wrote:

> Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you.
>
> https://forum.dlang.org/post/laqjadtwrsdhdrqokryx@forum.dlang.org

My assessment (which could be wrong):
`scope` and `return` only apply to pointers and `ref`s.  If you remove all `scope` and `return` attributes from the function `push`, it works fine.

I consider it a bug that the compiler doesn't emit an error when using attributes on types for which they are not intended.

Mike
May 17, 2019
On 17.05.19 06:50, Meta wrote:
> Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you.
> 
> https://forum.dlang.org/post/laqjadtwrsdhdrqokryx@forum.dlang.org

You don't like my explanation?

https://forum.dlang.org/post/q6r4bf$2hu4$1@digitalmars.com (same thread)
May 16, 2019
On 5/16/2019 9:50 PM, Meta wrote:
> Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you.
> 
> https://forum.dlang.org/post/laqjadtwrsdhdrqokryx@forum.dlang.org

As always, I recommend drastically reducing the example. It nearly always makes the actual problem emerge from all the noise.
May 17, 2019
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote:

> My assessment (which could be wrong):
> `scope` and `return` only apply to pointers and `ref`s.  If you remove all `scope` and `return` attributes from the function `push`, it works fine.
>
> I consider it a bug that the compiler doesn't emit an error when using attributes on types for which they are not intended.
>
> Mike

Working example:  https://run.dlang.io/is/TCP0td