docs: prepare v0.4.0 beta1 (#3812)

docs/index.rst

@@ -21,13 +21,14 @@ Because of this Vyper provides the following features:
 * **Support for signed integers and decimal fixed point numbers**
 * **Decidability**: It is possible to compute a precise upper bound for the gas consumption of any Vyper function call.
 * **Strong typing**
-* **Small and understandable compiler code**
-* **Limited support for pure functions**: Anything marked constant is not allowed to change the state.
+* **Clean and understandable compiler code**
+* **Support for pure functions**: Anything marked ``pure`` is not allowed to change the state.
+* **Code reuse through composition**: Vyper supports code reuse through composition, and to help auditors, requires syntactic marking of dependencies which potentially modify state.
 
 Following the principles and goals, Vyper **does not** provide the following features:
 
 * **Modifiers**: For example in Solidity you can define a ``function foo() mod1 { ... }``, where ``mod1`` can be defined elsewhere in the code to include a check that is done before execution, a check that is done after execution, some state changes, or possibly other things. Vyper does not have this, because it makes it too easy to write misleading code. ``mod1`` just looks too innocuous for something that could add arbitrary pre-conditions, post-conditions or state changes. Also, it encourages people to write code where the execution jumps around the file, harming auditability. The usual use case for a modifier is something that performs a single check before execution of a program; our recommendation is to simply inline these checks as asserts.
-* **Class inheritance**: Class inheritance requires people to jump between multiple files to understand what a program is doing, and requires people to understand the rules of precedence in case of conflicts ("Which class's function ``X`` is the one that's actually used?"). Hence, it makes code too complicated to understand which negatively impacts auditability.
+* **Class inheritance**: Class inheritance requires readers to jump between multiple files to understand what a program is doing, and requires readers to understand the rules of precedence in case of conflicts ("Which class's function ``X`` is the one that's actually used?").
 * **Inline assembly**: Adding inline assembly would make it no longer possible to search for a variable name in order to find all instances where that variable is read or modified.
 * **Function overloading**: This can cause lots of confusion on which function is called at any given time. Thus it's easier to write misleading code (``foo("hello")`` logs "hello" but ``foo("hello", "world")`` steals your funds). Another problem with function overloading is that it makes the code much harder to search through as you have to keep track on which call refers to which function.
 * **Operator overloading**: Operator overloading makes writing misleading code possible. For example ``+`` could be overloaded so that it executes commands that are not visible at a first glance, such as sending funds the user did not want to send.

docs/release-notes.rst

@@ -14,6 +14,14 @@ Release Notes
     for advisory links:
     :'<,'>s/\v(https:\/\/github.com\/vyperlang\/vyper\/security\/advisories\/)([-A-Za-z0-9]+)/(`\2 <\1\2>`_)/g
 
+v0.4.0b1 ("Nagini")
+*******************
+
+Date released: 2024-03-01(?)
+============================
+
+v0.4.0 represents a major overhaul to the Vyper language. Notably, it overhauls the import system and adds support for code reuse. It also adds a new, experimental backend to Vyper which lays the foundation for improved analysis, optimization and integration with third party tools.
+
 v0.3.10 ("Black Adder")
 ***********************