Revive the unified call syntax.

[yakito...@gmail.com]

hello.

i very hope revive Unified Call Syntax.i say as UCS.

UCS is very visualizerble function chain.so good.

i have more thing.

i see the future.

UCS with constexpr make big paradim.

//--ex...

constexpr somearray sa{//.....}

constexpr auto map(auto a,auto f){

    for(auto& o:a) o=f(a);

   return a;

}

constexpr auto reduce(auto a,auto f){

    somearray r;

    for(auto& o:a){

         if(f(o)){

              r.push_back(o);

         }

    }

    return r;

} 

constexpr auto get(auto a){ return a;}

sa.map([](){}).reduce([](){}).get();//MAYBE... this line process in complie time.

//--- over

this structure is very effective.

and some compile vender asked dinamic memory on compile time.

more  funny thing is come.

why i say?

i dont have right for the write the proposal.

i can only ask you."i have interest.please write one."

Please.REVIVE Unified call syntax.

BIG HOPE OF ME.

[yakito...@gmail.com]

more good one thing for that.

it is BINDING TIME.

temporary value is easy destroy by used.

but once bind to vriable.so get life for unkown time.

memory is resuorces.use to cheep for good.

ah... one more suggested good thing.

Please. REVIVE.

[Richard Hodges]

I agree. It was a good proposal, and it will be missed.

In the meantime, here's a workaround which gives you the syntax you want:

http://coliru.stacked-crooked.com/a/763ab2730688f8da

#include <string>

#include <utility>

#include <ciso646>

#include <iostream>

#include <tuple>

#include <string_view>

#include <memory>

#include <vector>

#include <algorithm>

#include <numeric>

// the concept of a capacity

struct capacity 

{

    constexpr capacity(std::size_t x) : value_(x) {}

    constexpr operator std::size_t() const { return value_; }

    std::size_t value_;

};

// not every container supports reserve() so stub it out in the general case

template<class Container>

void reserve(Container&&, std::size_t)

{}

// implement reserve for any vector

template<class T, class A>

void reserve(std::vector<T, A>& vec, std::size_t x)

{

    vec.reserve(x);

}

// wrap any container with a library of operations

template<class Container>

struct ops : Container

{

    using container_type = Container;

    using value_type = typename container_type::value_type;

    ops(capacity cap)

    : container_type()

    {

        reserve(my_container(), cap);

    }

    ops(Container&& c) : Container(std::move(c)) {}

    // return a reference to the underlying container

    container_type& my_container() {

        return static_cast<container_type&>(*this);

    }

    template<class F>

    ops map(F&& f)

    {

        auto&& source = my_container();

        auto result = ops(capacity(source.size()));

        std::transform(source.begin(), source.end(), std::back_inserter(result), f);

        return result;

    }

    template<class F = std::plus<>>

    auto fold(value_type init = value_type(0), F&& f = F())

    {

        auto&& source = my_container();

        return std::accumulate(source.begin(), source.end(), init, f);

    }

};

// test

int main()

{

    auto o = ops(std::vector{1,2,3,4});

    auto times_two = [](auto x) { return x * 2; };

    auto tot = o.map(times_two).fold();

    std::cout << tot << std::endl;

}

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bfdd9fc5-d044-4804-96d5-b74fac28589a%40isocpp.org.

[Gašper Ažman]

Definitely plans for that. Stay tuned.

G

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bfdd9fc5-d044-4804-96d5-b74fac28589a%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haqDbyfxo3TMbqBoQ%2BBEE2s8vOZNBGfwKc3bo26m%2BEofw%40mail.gmail.com.

[yakito...@gmail.com]

Yes! Yes!! your skill is hier then me.

but i think for only container.

mainly thing is compile time prosessing to the meaning blocks.

i cant think so your method. you great! and i think your method is bit closes

if i write template function to think effect is maximum effective.

that method no resons write by template.

my pushing point is...

UCS with constexpr make big paradim.

"with" is important!

but anyway...

wait for dynamic memory on constexpr.

that future alive time. hoping peaces cleard.

i hate bad knowhow.i wanna under clear light.

yes i say kidding.

but like the it's futuer so hope.

oh sorry.

i think.

time is still young.

i am wait for hoping futuer.

thank you  for your suggettion and support.

[yakito...@gmail.com]

my opnion of one of C++ future.

constexpr can makes big dictionary on compile time.

run time is search and use it dictionary.

constexper funtion chain is processed chain and erase the page.

remain is processed memory.it as dictionary.

so.next age is total memory spec is important.

this is all of spec. i think.

big dictionary as program.i see that future.

[Matthew Woehlke]

On 2018-03-14 21:18, yakito...@gmail.com wrote:
> i very hope revive Unified Call Syntax.i say as UCS.
> UCS is very visualizerble function chain.so good.

Apologies for the thread necro, and this isn't *quite* in the same
vein... but I had the same thought just the other day. (That said, I
will also acknowledge that I think I might have voted *against* UCS a
while back. Eh, well... it has concerns as well as benefits, what else
can I say?)

Specifically, I wanted to use this little helper:

template <typename Container, typename Key>
auto get(Container const& c, Key const& key)
-> decltype(std::addressof(*c.find(key)))

...but alas, it doesn't work on vectors. I could rewrite it using
`std::find`, but does that DTRT on associative containers that have some
form of fast look-up? And do I want `std::find`, or `find` in an
associated namespace? Because... it's super awkward to write the latter
(no `using namespace` inside of `decltype`).

Now, I realize in this specific instance I can probably answer those
questions... that's not the point. This comes up also with `swap`,
`begin` and so forth. UCS could drastically simplify this sort of thing.

--
Matthew