Am Sonntag, den 31.01.2021, 20:49 +0100 schrieb Corentin:
> On Sun, Jan 31, 2021 at 8:43 PM Uecker, Martin via Liaison <
> liaison_at_[hidden]> wrote:
>
> > Am Sonntag, den 31.01.2021, 17:37 +0000 schrieb Niall Douglas via Liaison:
> > > On 30/01/2021 22:27, Uecker, Martin wrote:
> >
> > ...
> >
> > > > If C++ rejects dependent types because C++ people "dislike" them
> > > > (as you said above), then your type system will remain limited in
> > > > what you could do with it. Of course, external tools could
> > > > always attach their own more powerful types to C++ terms, but
> > > > the C++ type system could not help.
> > >
> > > Thanks for all the exposition I didn't reply to in order to keep this
> > > reply short.
> > >
> > > Don't get me wrong here, other C "successors" went the dynamic runtime
> > > type route, Objective C being the most obvious, but C# is another famous
> > > one. Whilst there is nothing wrong with languages such as Objective C or
> > > C#, in my personal opinion I would say that their time has passed
> > > relative to better alternatives.
> > >
> > > I don't want to make too sweeping a statement, but in my experience
> > > dynamic runtime types never optimise well. If you write your Python with
> > > static types, Pyston will optimise the snot out of it. If you write your
> > > Python with dynamic types, Pyston gives up very easily.
> > >
> > > I'm not a language person, nor a compiler person, but it seems to me
> > > that dynamic runtime types do not easily produce bare metal execution
> > > performance. I think indirection of dynamic information whilst keeping
> > > the top level of the type system 100% static is a better design approach.
> >
> > I think this is a bit of misunderstanding. What you have
> > been describing is that C++ is erasing the length from
> > the type and making it a run-time property. But this
> > allows for less static type analysis not for more.
> >
> > A type like
> >
> > std::span<T>
> >
> > which is something like
> >
> > template <typename T>
> > struct span {
> > size_t len;
> > T* ptr;
> > };
>
>
> > erases any information about the length from the type.
> > This more like dynamic languages with weak typing and
> > the opposite of what C is doing here.
> >
>
> FYI, size erasure is the default but it isn't required
> http://eel.is/c++draft/views.span#span.overview-2

You mean it can have a static constant size as
part of the type or dynamic. Thanks for letting
me know I wasn't aware of this! But the
interesting case are the dynamic bounds...

Best,
Martin


> >
> > A regular static array type like T[5] has the full length
> > information in the type. A VM type like T[N] in C also
> > has the length information as run-time property. But
> > it still has static information about this dependency
> > in the type. You know for example that T[N] and T[M]
> > are compatible iff N == M and you know this conditional
> > property statically.
> >
> > You can easily read form the types, for example, that in
> > the following function *a and *b have compatible types:
> >
> > void foo(int N, double (*a)[N], double (*b)[N])
> > {
> >
> > }
> >
> > In contrast, if you have
> >
> > void foo(std::spawn<T> a, std::spawn<T> b)
> > {
> >
> > }
> >
> > you do not know this statically! So the C approach
> > has more information available at compile time - not
> > less.
>
>
> >
> > Best,
> > Martin
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2021/01/0284.php
> >