Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Contracts for C

gustedt.wordpress.com

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Contracts for C

#31

Post by sirwhinesalot »

miropalmu wrote: post #28
sirwhinesalot wrote: post #24

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh

What do you mean no slice/span type? https://en.cppreference.com/w/cpp/container/span.html Or if you want multidimensional span: https://en.cppreference.com/w/cpp/container/mdspan.html

C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages.

Re: Contracts for C

#32

Post by pjmlp »

arunc wrote: post #25
motorest wrote: post #17

Earlier quoted context omitted.

> Digital Mars C++ has had contracts since, oh, the early 1990s? I think that implementations trying out their own experimental features is normal and expected. Ideally, standards would be pull-based instead of push-based. The real question is what prevented this feature from being proposed to the standardization committee.

It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.

People keep forgetting C++ design is driven by 300+ people, and the features that get into the language go to elections, that they have to win.

Stroustoup has one vote, not everything he advocates for wins votes, including having a saner C++ (Remember the Vasa paper).

Re: Contracts for C

#33

Post by pjmlp »

sirwhinesalot wrote: post #24

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh

Strange are the ways of security in WG14.

Re: Contracts for C

#34

Post by pjmlp »

__d wrote: post #2

I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?

Languages are software products like everything else in computing, either they evolve or they whither and die.

C especially was designed with lots of security defects, and had it not been for UNIX being available for free, it would probably never taken off.

Re: Contracts for C

#35

Post by sirwhinesalot »

veltas wrote: post #27
sirwhinesalot wrote: post #24

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh

You can do f(int n, int (*a)[n]) and it does what it looks like, since C99. https://godbolt.org/z/8dfKMrGqv

That's an entirely different thing (VLAs)

Re: Contracts for C

#36

Post by motorest »

arunc wrote: post #25
motorest wrote: post #17

Earlier quoted context omitted.

> Digital Mars C++ has had contracts since, oh, the early 1990s? I think that implementations trying out their own experimental features is normal and expected. Ideally, standards would be pull-based instead of push-based. The real question is what prevented this feature from being proposed to the standardization committee.

It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.

> It was proposed by Walter and denied by Stroustroup, probably to save C++.

Citation needed.

For starters, where is the paper?

Re: Contracts for C

#37

Post by pjmlp »

HexDecOctBin wrote: post #7
jimbob45 wrote: post #4

Earlier quoted context omitted.

Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?

People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…

No, many people chose C, because they had to.

Re: Contracts for C

#39

Post by miropalmu »

sirwhinesalot wrote: post #31
miropalmu wrote: post #28

Earlier quoted context omitted.

What do you mean no slice/span type? https://en.cppreference.com/w/cpp/container/span.html Or if you want multidimensional span: https://en.cppreference.com/w/cpp/container/mdspan.html

C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages.

Oh. Makes sense. My bad.

Re: Contracts for C

#40

Post by pjmlp »

nananana9 wrote: post #8
jimbob45 wrote: post #4

Earlier quoted context omitted.

Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?

The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…

Most single C implementations have died out.

There is hardly any C compiler worth using that isn't equally a C++ compiler .

In fact, there is any C compiler left worth using that hasn't been rewriten into C++.

Post reply on HN