On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d wrote:
> On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice.
>
> Not for or against the DIP, but this is already the case, due to block attributes. I have to search around the file to find out whether pure: is at the top, etc. In fact, I've made recommendations many times on PRs to add an attribute to a function, to find out it's already handled at the top.
>
> I would think documentation generation should solve the issues.

Honestly, I tend to be against block attributes for this very reason, but at least with block attributes, you can grep/search the file and find the information. With this DIP, you potentially have to go looking in other libraries to figure out which attributes actually apply, and you have to track down every attribute on a function just to figure out whether a built-in attribute applies to it. And I bet the documentation generation (at least as it stands) would just put the custom attributes on there and not translate them to their constituent attributes. But even if it put all of the attributes on there individually, honestly, I think that it's a huge negative if I have to run the documentation generation to figure out what some code is doing. IMHO, I should be able to read the code and see what it's doing without running extra tools or searching through several other projects. Sometimes (particularly with more complicated code where you have to understand other functionality to understand the stuff in front of you), life doesn't work that way, but that should be the goal. And aliasing and combining attributes goes completely against that goal. Stuff like block attributes already harm it, but at least they're localized.

- Jonathan M Davis

On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
[...]
> If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions.

There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
> On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
> [...]
>> If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions.
>
> There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.

You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.

On 22.08.2017 21:46, 12345swordy wrote:
> On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
>> On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
>> [...]
>>> If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions.
>>
>> There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
> 
> You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.

I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature.

On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:
> I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature.

Indeed, I can't imagine a DIP suggesting to make core regular attributes, keyword like getting very far had those attributes been added after we got UDAs.

While IDEs may be able to show you instantly what attributes a function has, so would the compiler (in the form of an errors message if you got it wrong, quality of said message notwithstanding), documentation, any dcd based tooling (or any other tools that can do symbol resolution) and code searches.

If the tooling is insufficient for this use case, then it should be improved as this is a problem that is able to be solved completely by tooling. If you choose not to use the tooling, and it would solve this problem, then that is fine, but I don't think we should limit the design of the language because of that.

On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:
> On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
>> On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
>> [...]
>>> If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions.
>>
>> There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
>
> You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.

Platitudes cause poor language design, not the completely reasonable expectation of good tools.

On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:
> On 22.08.2017 21:46, 12345swordy wrote:
>> On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
>>> On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
>>> [...]
>>>> If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions.
>>>
>>> There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
>> 
>> You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.
>
> I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature.

"Required" is a bit of a strong word here. In the absence of good practice, any language feature can be abused to make code confusing.

Function overloading is a good example of a feature that is usable as is, but made much better with a good IDE. But the same way I wouldn't name every function in a class "performAction" and pass a 50 member enum to it to tell it what to actually do, I wouldn't have more than 4-5 different types of function attribute combinations, and if I did, I wouldn't spread them out among 10 different files. What little extra effort it takes to look up the attributes of a function in an atmosphere of good practice can easily be made up for with good tools, and no one _has_ to use bundled up attributes.

On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
> On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:
>> On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
>>> On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
>>> [...]
>>>> [...]
>>>
>>> There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
>>
>> You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.
>
> Platitudes cause poor language design, not the completely reasonable expectation of good tools.

And who is "Platitude" here specifically?

On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:
> On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
>> [...]
>>
>> Platitudes cause poor language design, not the completely reasonable expectation of good tools.
>
> And who is "Platitude" here specifically?

http://lmgtfy.com/?q=platitude ;)

On Thursday, 24 August 2017 at 01:38:50 UTC, bitwise wrote:
> On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:
>> On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
>>> [...]
>>>
>>> Platitudes cause poor language design, not the completely reasonable expectation of good tools.
>>
>> And who is "Platitude" here specifically?
>
> http://lmgtfy.com/?q=platitude ;)

How about actually answering the question instead of assuming that I can't look up the definition of any words?