DIP1028 - Rationale for accepting as is

[rikki cattermole]

On 23/05/2020 5:40 AM, Atila Neves wrote:
> On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote:
>> On 23/05/2020 5:07 AM, Atila Neves wrote:
>>> [...]
>> It is not about the linkage.
>>
>> The problem is solely does the compiler have the source to the 
>> function body to verify it?
> 
> That's what I meant, sorry for not making it clearer.

It kept being swapped about in the discussion thread, so I have been a 
little on edge over people using non-extern(D). Because linkage doesn't 
mean anything to anything but to cpu and linker in this discussion.

>>> [...]
>>
>> That is a failure of the language that should be resolved.
> 
> And how do you suggest we fix it?

I don't know.

It is a problem that needs to be explored in more detail.

Adam had one idea that I convinced him to write up, but that didn't get 
very far when commented relating to propagation of attributes.

Major changes like this, should have been discussed and RFC'd instead of 
going to straight to a DIP. That is effectively what happened.

>>> [...]
>>
>> No.
>>
>> We simply do not agree, nor do I expect for us to come to terms on it 
>> anytime soon.
> 
> I meant "did I explain myself well enough that now you understand where 
> I'm coming from, even though you might not ultimately agree?".

Yeah.

-------------

I didn't look at the binding, since you described it well previously, 
but of note is that you used @safe. What you should have used is 
@trusted instead.

If the programmer wants to slap @trusted: at the top of the file, I have 
no problems with that. You checked it (i.e. its LLVM, so of course its 
fine!).