Re: [boost] [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Gonzalo BG (gonzalobg88_at_[hidden])
Date: 2014-08-01 05:02:25

I'm a bit worried that:
- Hana exposes a C++1y library-based implementation of concepts on its
interface (typeclasses). Would moving it to concepts (once we get
language-support in 2015/16) introduce a big breaking change?

Then, Range-v3, TICK, Hana, and others are all using _different_ C++11/1y
library-based implementations of concept checking which I guess means that:
- there is need for such a library, and
- Boost.ConceptCheck is for whatever reason not good enough in C++11/1y
world yet.

On Fri, Aug 1, 2014 at 2:26 AM, Edward Diener <eldiener_at_[hidden]>
wrote:

> On 7/31/2014 6:28 PM, Niall Douglas wrote:
>
>> On 31 Jul 2014 at 10:11, Eric Niebler wrote:
>>
>>  On 07/29/2014 05:14 PM, Niall Douglas wrote:
>>>
>>>> I'm all for Concepts as in compiler enforced ones, and I'll add them
>>>> to AFIO when and only when C++ gets them. But for documentation they
>>>> don't help.
>>>>
>>>
>>> Wow, I couldn't disagree more. I can't imagine how the standard
>>> algorithms would be specified without the use of concepts like
>>> "RandomAccessIterator", for instance. Clustering requirements into
>>> meaningful abstractions and assigning them names makes it possible to
>>> document library interfaces without an explosion of verbosity and
>>> repetition.
>>>
>>
>> Oh I know programmers similar to how you visualise code in your head
>> would agree with you absolutely. But you must remember programmers
>> like me don't see C++ as really in fact having types nor classes nor
>> concepts - I just see methods of programming the compiler to output
>> patterns of assembler code, and I think primarily in terms of chains
>> of assembler instructions. My type of programmer learns just enough
>> of the verbiage to understand C++ Now presentations by programmers
>> such as you (and I haven't failed to learn something new from yours
>> yet), but we'll never think like you any more than you'll think like
>> us.
>>
>> None of this a bad thing of course, diversity of approach and all.
>> But to me and people like me a RandomAccessIterator is a pointer and
>> is little different to a ForwardIterator. I care about the difference
>> only in so far as I can use it to get the compiler to generate code
>> one way or another according to need. I furthermore care about the
>> difference only in so far as it will get later maintainers and team
>> members to behave one way instead of another. Past that I feel no
>> issue reinterpret casting STL internal types to bypass the type
>> system if that gets me the assembler output I want and doesn't create
>> maintenance debt later.
>>
>> It's the essential difference between language-focused coders and err
>> ... mongrel coders? I have to admit I'm not sure what to call myself
>> really. Either way, I see ConceptCheck as a half baked feature giving
>> me nothing useful but bloat and complexity and significantly adding
>> mess to documentation and steepening my learning curve. I absolutely
>> can't wait for language support for Concepts, and will use them with
>> vengence when they turn up as they're another great tool for bending
>> the compiler in new ways, but until it's fully baked as a language
>> feature they get in my way. And hence I don't use them personally,
>> and groan every time I'm faced with code by someone who has (no
>> offence intended here, we all have our own personal likes and
>> dislikes, and I entirely understand your opinions on this and respect
>> them, I just don't have those opinions myself).
>>
>
> With all due respect to your super-practical low-level approach I think
> you must know that you are very much in the minority. Practical
> programming, as you reflect on above, certainly has its advantages but
> without knowing what one can do with a programming language I see it as
> impossible to design robust code that is both understandable and usable to
> others and effective in accomplishing its goal.
>
> I do not think 'concepts', aka largely 'type constraints' as Robert as
> aptly renamed it in this discussion, is a panacea for every template
> programming problem. But understanding the 'domain' of what a 'type'
> entails is just as important as understanding the 'domain' of some
> parameter in a function call. Without documentation of such things the user
> of your constructs has no idea what will work and what will not work and
> programming then becomes and endlessly wasteful game of trial and error.
>
> Nor is that really 'language-focused' programming. Its just programming
> that takes into account that others must usually be able to use what you
> create else it is worthwhile only to yourself and your own solution to a
> problem.
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>