On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
> Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it).

DMD will. I don't know about LDC or GDC.

On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote:
> On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
>> Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it).
>
> DMD will. I don't know about LDC or GDC.

It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.

On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via Digitalmars-d-announce wrote:
> On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- announce wrote:
[...]
> > The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated.

I'm also against implicit slicing of static arrays. It's just too dangerous, and also interacts poorly with template functions.


> The trick is convincing Walter. The last time I brought it up with him, he thought that improvements to @safe would fix the problem - and they will help - but it interacts badly with templated code, and I think that from a code clarity standpoint, the slicing needs to be explicit. So, I'm of the opinion that implicit slicing should simply be deprecated regardless of the state of @safe, but I don't know how possible it is to convince Walter of that. Fixing the @safe issues is at least a start though.
[...]

It's true that fixing @safe issues will at least reduce the problem surface of implicit slicing. But it's like bandaid over a festering wound; the problem is still there, it just lurks in more obscure corners now.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher

On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- announce wrote:
> I would add a note to the "static arrays are interchangeable with dynamic arrays" saying that you can... and probably should explicitly slice them with `[]`.
>
> The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated.

The trick is convincing Walter. The last time I brought it up with him, he thought that improvements to @safe would fix the problem - and they will help - but it interacts badly with templated code, and I think that from a code clarity standpoint, the slicing needs to be explicit. So, I'm of the opinion that implicit slicing should simply be deprecated regardless of the state of @safe, but I don't know how possible it is to convince Walter of that. Fixing the @safe issues is at least a start though.

- Jonathan M Davis

On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
> It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.

It's already there under:

    version (DigitalMars)

On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote:
> On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
>> It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.
>
> It's already there under:
>
>     version (DigitalMars)

I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks!

On 7/7/2017 6:28 PM, Walter Bright wrote:
> On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
>> It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.
> 
> It's already there under:
> 
>      version (DigitalMars)

Just to beat that dead horse into the dust:

    https://github.com/dlang/druntime/blob/master/src/core/stdc/stdlib.d#L216

On 7/7/2017 6:51 PM, Mike Parker wrote:
> I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks!

alloca() being a compiler intrinsic means the version should be about the host compiler, not the particular runtime (though they usually go together, but not always).

On 7/7/17 9:51 PM, Mike Parker wrote:
> On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote:
>> On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
>>> It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.
>>
>> It's already there under:
>>
>>     version (DigitalMars)
> 
> I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks!

Ha! as someone who doesn't regularly develop on Windows, I didn't even test.

I should have known better, as I've used alloca in druntime, and that wouldn't work if it didn't build on Win64.

-Steve