Update intro examples

doc/intro.md

@@ -30,8 +30,8 @@ example, given an instance of the `Account` type assigned to the variable
 
 ```proto
 has(account.user_id) || has(account.gaia_id)    // true if either one is set
-size(account.emails) > 0                        // true if emails is non-empty
-matches(account.phone_number, "[0-9-]+")        // true if number matches regexp
+account.emails.size() > 0                       // true if emails is non-empty
+account.phone_number.matches("[0-9-]+")         // true if number matches regexp
 ```
 
 CEL expressions support most operators and functions one would expect when
@@ -60,7 +60,7 @@ doesn't have a matching protocol buffer type. Within CEL, these objects support
 the same accesses and functions as protocol buffer types:
 
 ```proto
-has(account.properties.id) && size(account.properties.id) > 0
+has(account.properties.id) && account.properties.id.size() > 0
 ```
 
 When the expression `account.properties` is evaluated, CEL will automatically
@@ -85,7 +85,7 @@ citizens of CEL:
 ```proto
 has(account.properties.id)
   && (type(account.properties.id) == string
-     || type(account.properties.id) == list(string))
+     || type(account.properties.id) == list)
 ```
 
 CEL's default type checker deals with a mixture of dynamic and static typing;

doc/langdef.md

@@ -632,7 +632,7 @@ A CEL expression is parsed and evaluated in the scope of a particular protocol
 buffer package, which controls name resolution as described above, and a binding
 context, which binds identifiers to values, errors, and functions. A given
 identifier has different meanings as a function name or as a variable, depending
-on the use. For instance in the expression `size(requests) > size`, the first
+on the use. For instance in the expression `requests.size() > size`, the first
 `size` is a function, and the second is a variable.
 
 The CEL implementation provides mechanisms for adding bindings of variable names
@@ -914,7 +914,7 @@ size of the inputs.
     cost of `O(P * I)`, and see below.
 *   Eliminating all of the above and using only default-cost functions, plus
     aggregate literals, time and space are limited `O(P * I)`.
-    A limiting time example is `size(x) + size(x) + ...`.
+    A limiting time example is `x.size() + x.size() + ...`.
     A limiting time and space example is `[x, x, ..., x]`.
 
 Note that custom function will alter this analysis if they are more expensive
@@ -942,31 +942,31 @@ specified by the following overloads:
       size
     </th>
     <td>
-      (string) -> int
+      string.() -> int
     </td>
     <td>
       string length
     </td>
   </tr>
   <tr>
     <td>
-      (bytes) -> int
+      bytes.() -> int
     </td>
     <td>
       bytes length
     </td>
   </tr>
   <tr>
     <td>
-      (list(A)) -> int
+      list(A).() -> int
     </td>
     <td>
       list size
     </td>
   </tr>
   <tr>
     <td>
-      (map(A, B)) -> int
+      map(A, B).() -> int
     </td>
     <td>
       map size
@@ -2156,31 +2156,31 @@ See [cel-go/issues/9](https://github.com/google/cel-go/issues/9).
       size
     </th>
     <td>
-      (string) -> int
+      string.() -> int
     </td>
     <td>
       string length
     </td>
   </tr>
   <tr>
     <td>
-      (bytes) -> int
+      bytes.() -> int
     </td>
     <td>
       bytes length
     </td>
   </tr>
   <tr>
     <td>
-      (list(A)) -> int
+      list(A).() -> int
     </td>
     <td>
       list size. Time cost proportional to the length of the list.
     </td>
   </tr>
   <tr>
     <td>
-      (map(A, B)) -> int
+      map(A, B).() -> int
     </td>
     <td>
       map size. Time cost proportional to the number of entries.